Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

[Keith OHara]

On Sat, 05 Nov 2011 04:19:47 -0700, address@hidden <address@hidden> wrote:

> On Nov 4, 2011, at 2:35 PM, Keith OHara wrote:
>
> > The bug happens when the piece is entirely hight notes. (I should add some 
> > intelligence to handle this case, so that we can use 'skyline-vertical-padding 
> > without this annoyance.)  Any single protrusion below the staff anywhere in the 
> > piece lets the lyrics slide under.
>
> Why are you interested in keeping skyline-vertical-padding?

It has been working well for a long time.   It is a nice way to request a 
visual separation with rounded corners.
All skylines have beveled margins.  Their size when used for note-spacing was 
hard-coded for a long time, was set to zero in the 2.13 versions, then recently 
we added the property so they could be set differently for 
NonMusicalPaperColumns versus NoteColumns.  Individual Grobs can request 
extra-spacing-width/height, as your patch does.

Your patch keeps skyline-vertical-padding, just removing one override of its 
value. In any event I want to adjust the note-spacing routine to look at the 
columns when with Staves at their desired spacing (rather than temporarily 
assuming full compression).  Then the skyline-vertical-padding and your 
extra-spacing height will not push horizontally on items from other 
staff-like-contexts, when we really asked for the items to clear vertically. 
(Started testing a patch last week.)

> I don't know the full history behind the creation/maintenance of the property, 
> but it seems to me that this is a one-size-fits-all property that, if 
> eliminated, would allow for more subtle solutions on a grob-to-grob basis.  
> Currently, for example, the same property is causing ChordNames to expand 
> measures if all the chords in a piece fall below the upper extreme of the staff 
> (see chord-name-exceptinos.ly, for example).  Furthermore, I'm always weary 
> about magic #s that are based on an overridable layout decision.  The existence 
> of ledger lines for notes is not always guaranteed, and if they exist, they can 
> be moved, in which case the 0.6 that's the current value would no longer work.

I worry because you make the spacing given to bar lines rather independent of 
the printed extent of bar lines, and the way you calculate the space uses a 
part of LilyPond that I find hard to understand.  I continue to worry until I 
see some evidence that someone besides you understands the patch.