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

Reply via email to