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

[address@hidden]

On Nov 4, 2011, at 1:52 AM, Keith OHara wrote:

> 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.
> 

I think that it is easier to tweak this sort of thing of bar lines know about 
the existence of leftward-hanging grobs and can deal with them.

>> 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:

It's true that this patch conserves the old behavior in that regard with my 
most recent additions.  I still stand by that, but I think the only way to make 
spacing more tweakable is, like I've been saying all along, to have grobs aware 
of the existence of others to the left and right.  This is already accomplished 
via NoteSpacing and StaffSpacing, and the Pure_from_neighbor idea reinforces 
this.

>> 
>> 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.

The fix to get folded clefs correct reverts the old behavior, but again, I 
think that by working from this base, you can accomplish more.  In general, 
responding to your initial question, the long term plan for this interface and 
engraver is to get grob heights relative with respect to other grobs.  From 
this position, you can do more sophisticated spacing tweaking.

> 
>>> 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?
> 

No.  Check out http://www.apollinemike.com/first.pdf .  This is one of the many 
pieces where these changes will be beneficial.

> 
>>> 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?

Pure relevant is used all over the code.  If you'd like to change it, I think 
that should be proposed by another patch.

> 
> 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>
> 

The only reason that this guy was able to pull through was because he read the 
code and realized that, even though the meaning of pure was a stretch compared 
to the definition on Wikipedia, the naming conventions across LilyPond were 
consistent.  This provides a sort of rosetta stone for the inquisitive mind.  I 
would rather name something along the convention found in other places in the 
code, even if this convention can be rethought, than be unique in my naming.

So, as I've said above & in an e-mail to David, I'm all for thinking out better 
ways to name variables/interfaces/engravers in the code, but it should be 
consistent.  And, for now, I believe that my use of "pure relevant" is in 
keeping with how the phrase is used throughout the source code.

Cheers,
MS