Re: [Lilypond-auto] Issue 3160 in lilypond: chord names pushed into the staff

[lilypond]

Comment #8 on issue 3160 by address@hidden: chord names pushed into  
the staff
http://code.google.com/p/lilypond/issues/detail?id=3160

> I think it's important to maintain this distinction.
You did not describe the distinct things, between which to maintain "this  
distinction".

I suggest that the two things are
1) graphical objects, having outlines stored in a skyline, for which we  
allow space including the requested padding
2) the conceptual presence of a line, whether empty or not, which we use to  
determine how many baseline-skips to apply, based on the basic-distance and  
minimum-distance property of the line.

LilyPond keeps these concepts mostly distinct. For example we have the  
option remove-empty to control if an absence of events on a line should  
remove the entire line.  Some the page-spacing code, however, assumes that  
graphically empty lines are to be conceptually removed, while other code  
does not, raising issue 1669.

> So, for example, you could create a transparent stub grob that causes the
> VerticalAxisGroup of Dynamics to always have a skyline.

Probably we do not want this (and if I understand correctly you bring it up  
to show why you do not want it).  Notes and protrusions from the Staff  
above and below often protrude through gaps in an intervening Lyrics or  
Dynamics line.

> Thus, a baseline cannot be established to it because it is "solid"  
> nowhere.

Well, we can and do space lines based on their 'basic-distance properties  
when the skylines of these lines are well clear of each other.   In several  
cases, a graphically empty line has its baseline spaced this way---for  
example, the way version 2.16 sets the input at the top of this issue.

The only place I see where the spacing code completely skip lines that are  
graphically empty is in align-interface.cc:get_skylines().  From the  
comments on issue 1669 we see that the reason for this skipping was to  
estimate page heights better, assuming empty lines would be removed under  
the remove-empty mechanism.  It would seem better to test under the actual  
remove-empty rules, which
 Hara_kiri_group_spanner::request_suicide (Grob *me, int start, int end)
will do for us, without actually removing the line, so we can get the  
correct answers for hypothetical layouts during the line-and-page-breaking  
stage.