Re: The mystery of vertical spacing

[Paul Hodges]

Thanks for this explanation, which puts flesh onto the understanding I'd 
been coming to.  However, I can't see what your example at the end is 
doing.  Commenting out the override makes no difference to the output, 
so a little explanation might help me.

What I guess I'd be interested in at this point is a way to force 
LilyPond to put the systems closer against its own (not in this case 
better!) judgement.  If not, for the time being I'll just have to reduce 
the font size slightly and accept the amount of space in the middle of 
the page.

As far as I can see, the stretchability parameter modifies the 
positioning of the staves on the page, but doesn't alter the decision 
about whether they can all be fitted on.

Paul


On 06/09/2021 00:44:52, "Jean Abou Samra" <jean@abou-samra.fr> wrote:

>Hi,
>
>>Okay. The problem seems to be that for the upper system the extent estimate is
>>larger than it should be. Consider setting the debug-skylines option (-ddebug-
>>display-skylines from CLI or #(ly:set-option debug-skylines) from file).
>>Maybe we find something.
>
>It took me a year of contributing to LilyPond to understand
>it, but these skylines are not actually relevant here.  Vertical
>skylines happen after line breaking has taken place -- how
>would we know the horizontal spacing to place the elements of
>the skyline if we don't have the page breaking configuration?
>So the role of vertical skylines in spacing is only in the page
>spacing step, where we have the systems that go on one page,
>with the line breaking configuration, and we want to best adjust
>the vertical positions of staves and systems on the page.
>
>For system extent estimates, the pure calculations are at play.
>At that stage, since we have no idea how the horizontal spacing
>will look like, we mostly make conservative estimates by considering
>every staff to be as tall as it is on its height maximum. That is,
>the possibility of snug spacing like
>
>------------------------------------------------
>
>------------------------------------------------
>                                            xccc
>------------------------------------------ xccc
>                                            x
>     x                                      x
>     x                                      x
>     x                                      x
>     x
>     x -----------------------------------------
>  cccx
>  cccx -----------------------------------------
>
>-----------------------------------------------
>
>
>is not considered at all and the estimation (except for
>some finer points) ends up as if the music was spaced as
>
>
>----------------------------------------------
>
>----------------------------------------------
>                                           xccc
>----------------------------------------- xccc
>                                           x
>                                           x
>                                           x
>                                           x
>
>     - + - + - + - + - + - + - + - + - + - +
>
>     x
>     x
>     x
>     x ----------------------------------------
>  cccx
>  cccx ----------------------------------------
>
>----------------------------------------------
>
>
>where the two stems avoid each other even if they are removed
>enough in the music that one would not think they could collide.
>
>The case here is a bit peculiar because, with number of staves it
>it has and the landscape page, knowing the final system heights
>using skylines could lead us to reconsider the page breaking
>configuration by just moving systems around between pages and not
>changing the breakpoints to others places in the music.
>LilyPond's page breaker is not prepared to handle that (yet).
>
>It's hard to be sure without the ability to experiment with the
>code, but if one does not get along with the stretchability Knute
>suggested, it might well be that LilyPond does not even consider
>the possibility of spacing the two systems on the same page,
>which can be due to the overly large extent estimates Valentin
>noticed. That might be caused by measure 27, where it can be
>seen that if the accent on the lower note is moved vertically
>below the upper stem with a minimal bit of padding, the system
>at large can get close to the over-estimated extent.
>
>Perhaps the override in the below example will help:
>
>\version "2.22.1"
>
>{
>   % The default value is
>   %   #(ly:make-unpure-pure-container ly:stem::height ly:stem::pure-height)
>   % so this nulls out the pure height.
>   \override Stem.Y-extent = #ly:stem::height
>   \stemUp
>   \repeat unfold 2000 { c'''8 }
>}
>
>
>Le 06/09/2021 à 01:10, Paul Hodges a écrit :
>>Setting that option draws coloured lines along the skyline.  At first
>>glance the lines hug the notation tightly throughout, as I'd expect.
>>But in the first line of the piece there are a couple of small oddities.
>>(1) towards the end of the third staff (bar 7, secondo), the top skyline
>>has a blip which doesn't relate to any object, except perhaps it relates
>>to (2) at the same place in the staff below there is a tuplet bracket
>>and clashing dynamics (which I intended to revisit later) which are
>>outside the "skyline" (do you have a name for the underneath one?).
>>
>>It occurs to me that this might be related the two occurrences of the
>>error: "programming error: cyclic dependency: calculation-in-progress
>>encountered for #'adjacent-pure-heights (VerticalAxisGroup); continuing,
>>cross fingers" which I have had since writing that page.
>
>That sounds like another instance of 
>https://gitlab.com/lilypond/lilypond/-/issues/6171.
>
>
>Best regards,
>Jean