On 27 févr. 2013, at 07:03, k-ohara5...@oco.net wrote:
> Just needs cleanup of some leftover unneeded complications.
>
>
> https://codereview.appspot.com/7310075/diff/38001/lily/skyline.cc
> File lily/skyline.cc (right):
>
> https://codereview.appspot.com/7310075/diff/38001/lily/skyline.cc#newcode488
> lily/skyline.cc:488: will be ignored.
> What do you mean by "they will be ignored"? On line 501, empty segments
> seem to be reversed, making non-empty segments.
>
Fixed. Bad copy and paste.
> https://codereview.appspot.com/7310075/diff/38001/ly/engraver-init.ly
> File ly/engraver-init.ly (right):
>
> https://codereview.appspot.com/7310075/diff/38001/ly/engraver-init.ly#newcode896
> ly/engraver-init.ly:896: \override Clef.Y-extent =
> #grob::all-heights-from-stencil
> Why the \overrride to the same value as its default ?
Fixed.
>
> https://codereview.appspot.com/7310075/diff/38001/ly/gregorian.ly
> File ly/gregorian.ly (right):
>
> https://codereview.appspot.com/7310075/diff/38001/ly/gregorian.ly#newcode103
> ly/gregorian.ly:103: \once \override BreathingSign.Y-extent =
> #grob::all-heights-from-stencil
> This is now the default, so no need for overrides.
Fixed.
>
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
>
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1825
> scm/define-grobs.scm:1825: (Y-extent .
> ,grob::unpure-empty-pure-point-height)
> (Y-extent . ,grob::all-heights-from-stencil)
>
> We do not /want/ to allow outside-staff objects to slide down alongside
> note-heads protruding from the staff, if by doing so they overlap any
> repeat ties that might be there.
I'll take this for a spin...not sure if it'll work but no harm regtesting it.
My goal was to preserve the original behavior, but if this is better no harm in
using it.
>
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1992
> scm/define-grobs.scm:1992: ; should preserve the span bar's presence for
> horizontal spacing
> "want this to be ignored" when ?
> Presumably during staff-spacing, but what problem could it cause if not
> ignored ?
>
It will be part of the skyline, potentially blocking things that shouldn't be
blocked.
> If staves would otherwise move away trying to make room for it, the
> SpanBar avoids this using cross-staff = ##t
The SpanBar has no height, so it is never taken into account in spacing.
>
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1993
> scm/define-grobs.scm:1993: (Y-extent .
> ,grob::unpure-empty-pure-point-height)
> (Y-extent . (0 . 0))
>
See above.
> https://codereview.appspot.com/7310075/diff/38001/scm/lily-library.scm
> File scm/lily-library.scm (right):
>
> https://codereview.appspot.com/7310075/diff/38001/scm/lily-library.scm#newcode629
> scm/lily-library.scm:629: (define-public small-empty-interval '(0.01 .
> -0.01))
> orphaned
>
Abandoned.
> https://codereview.appspot.com/7310075/diff/38001/scm/output-lib.scm
> File scm/output-lib.scm (right):
>
> https://codereview.appspot.com/7310075/diff/38001/scm/output-lib.scm#newcode69
> scm/output-lib.scm:69: (ly:make-unpure-pure-container #f '(0 . 0)))
> The changes to define-grobs.scm work for me, so this can be orphaned,
> thankfully.
I'm with you on RepeatTie, but not SpanBarStub. SpanBarStub needs to only have
height in Separation_item::boxes which is accomplished via the addition of
extra-spacing-height. Otherwise we don't want the spacing engine to know it's
there. This can be accomplished (for now) by having a point pure height and
adding the extra-spacing-height. The problem is that the notion "horizontal
spacing equals pure height plus extra spacing height" is hardcoded into
Separation_item::boxes. There should be horizontal-spacing-height and
horizontal-spacing-width instead of extra-spacing-height and
extra-spacing-width that has set as a default pure-height and width unless
specified otherwise.
But changing that would be a UI nightmare, so I'm reluctant to do it.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel