https://codereview.appspot.com/230860044/diff/20001/scm/define-grob-properties.scm File scm/define-grob-properties.scm (right):
https://codereview.appspot.com/230860044/diff/20001/scm/define-grob-properties.scm#newcode777 scm/define-grob-properties.scm:777: (parenthesis-friends ,list? "A lisy of symbols. Any parenthesis On 2015/04/19 19:32:29, Keith wrote:
"A list of Grob types, as symbols. When parentheses enclose a Grob
that has
'parenthesis-friends, the parentheses widen to include any child Grobs
with type
among 'parethesis-friends."
Done. https://codereview.appspot.com/230860044/diff/20001/scm/output-lib.scm File scm/output-lib.scm (right): https://codereview.appspot.com/230860044/diff/20001/scm/output-lib.scm#newcode908 scm/output-lib.scm:908: (define-public (parentheses-item::pure-y-extent grob start end) On 2015/04/19 19:32:29, Keith wrote:
I do not see why this function is necessary, but it looks correct.
There is a distinction between pure-y-extent and y-extent for objects
whose
vertical position or height might change depending on where the
line-breaks
fall.
Maybe it was formerly necessary for the accidental on the second note
of a tie,
which might disappear, but we let those accidentals have a simple
height now.
The only need I could see for pure-y-extent here, would be to estimate horizontal space for the parentheses around an accent outside a slur
or beam. So is it best to remove the code, since we don't have a regtest that exercises it? I think that if it turns out we need a pure-y-extent we'll know it because of a cyclic dependency when someone tries to use \parenthesize, and then we can reinstate the code and have a regtest for it. Do you agree? https://codereview.appspot.com/230860044/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
