Re: The mystery of vertical spacing

[Jean Abou Samra]

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