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

[Keith OHara]

On Fri, 04 Nov 2011 00:12:01 -0700, address@hidden <address@hidden> wrote:
> On Nov 3, 2011, at 11:39 PM, address@hidden wrote:
> > What is the overall plan for the new engravers?
>
> Currently, LilyPond has no mechanism to calculate the Y-extents of Items in a relative 
> way.  You can't say "make the height of grob X such that it is always Y larger than 
> that of grob Z."  This is necessary for grobs (like barlines) that need to block 
> certain grobs that fall above and below them.  [The same] for Staves, [the same] for time 
> signatures.  Currently, LilyPond accomplishes this through hardcoded values (checkout the 
> extra-spacing-height for TimeSignature, for example), which potentially catches unwanted 
> fuzz (a text script with '(0 . 0) for extra-spacing-width and low padding will be shifted 
> over numerical time signatures but not common time).

Generally, though, there is a desired spacing from the Time Signature to the 
main note column, and we usually do not want decorations like accidentals or 
text scripts to influence that spacing, unless necessary to avoid (near) 
collisions.

Issue 647 prompted the extra-spacing-height you mentioned, but that was for a 
(near) collision.  Personally, I think the comment added to 
'script-stack-horizontal.ly' was an overreaction.  If the note with lots of 
decorations is well clear, I would rather have the decorations folded over the 
Clef or whatever.

> In general, I'd like to see the Pure_from_neighbor_engraver take care of the 
> extra spacing heights for all grobs that are ordered by break alignments, as 
> all of them should prevent overhang.

Now, earlier you implied that change clefs were getting "too much space" in 
places where we blocked ledgers from overhanging:
> 2)      The elimination of skyline-vertical-padding corrects a horizontal
> spacing issue where the cue-clef takes up too much space in
> cue-clef-after-barline.ly and beam-collision-feasible-region.ly
I'm assuming you changed your mind.

> > I agree it would be nice to change this, but did you really see the
> > problem in real music?
>
> I see the problem in my music (which I consider real music!).
Wow.  Are you a minimalist?


> > What is a 'pure' when used as a noun?
>
> Grobs that are pure relevant.  I'll use "pure_relevants_" instead.
Purely relevant to what?  How can something be impurely relevant?

I know that you mean grobs that are relevant to the computation of an 
extra-spacing-height, for use in the note-spacing step, which comes before 
line-breaking, at which time we sometimes use approximate heights, which tend 
to be computed by functions that are (inaccurately) called 'pure'.
But, try to think of a less-jargony variable name, for the sake of this guy: 
<http://lists.gnu.org/archive/html/lilypond-devel/2011-05/msg00276.html>