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

[address@hidden]

On Nov 3, 2011, at 11:39 PM, address@hidden wrote:

> I'll try to make a patch so that note-spacing is not affected by
> potential collisions between grobs from different staff-like-contexts
> (fixing the rare Lyrics-barline interaction).  Then we can restore
> skyline-vertical-padding.
> 
> Net, with this patch and the other SpanBarStub patch, you've added 680
> lines of code containing two new engravers, to fix issue 910 and issue
> 1955.  I don't like the thought of maintaining that.
> 
> 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.  Idem for 
Staves, idem 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).

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.  This patch already does a good chunk of 
work for that.

This engraver will also be essential for cross staff stems, which I plan to 
implement and which will need spacing stubs on the staves they cross whose 
heights can be calculated via this engraver.

> http://codereview.appspot.com/5323062/diff/12001/input/regression/lyrics-pass-under-bar.ly
> File input/regression/lyrics-pass-under-bar.ly (right):
> 
> http://codereview.appspot.com/5323062/diff/12001/input/regression/lyrics-pass-under-bar.ly#newcode4
> input/regression/lyrics-pass-under-bar.ly:4: texidoc = "Long lyrics
> should be allowed to pass under
> They do so, except in very rare cases in short examples where nothing
> protrudes from the staff.
> 
> 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!).

> http://codereview.appspot.com/5323062/diff/12001/lily/pure-from-neighbor-engraver.cc
> File lily/pure-from-neighbor-engraver.cc (right):
> 
> http://codereview.appspot.com/5323062/diff/12001/lily/pure-from-neighbor-engraver.cc#newcode32
> lily/pure-from-neighbor-engraver.cc:32: vector<Grob *> pures_;
> This takes the lilypond-jargon 'pure' even further from its original
> inspiration (a pure function that does not depend on nor change program
> state).
> What is a 'pure' when used as a noun?
> 

Grobs that are pure relevant.  I'll use "pure_relevants_" instead.

> http://codereview.appspot.com/5323062/diff/12001/scm/define-grob-properties.scm
> File scm/define-grob-properties.scm (right):
> 
> http://codereview.appspot.com/5323062/diff/12001/scm/define-grob-properties.scm#newcode583
> scm/define-grob-properties.scm:583: (neighbors-filtered ,boolean?
> "Callback to filter an element list.")
> But 'neighbors-filtered' is not the callback, but the resulting list, is
> it not?
> The question I look here to answer is "how does LilyPond behave
> differently if elements-filtered is changed?"
> 

It does nothing...this is bad property.  I'll get rid of it tomorrow.

Cheers,
MS