Re: lilypond-book-preamble and cropping

[David Kastrup]

"Urs Liska" <address@hidden> writes:

> 30. Juli 2019 11:16, "David Kastrup" <address@hidden> schrieb:
>
>> "Urs Liska" <address@hidden> writes:
>> 
>>> I'm not sure if this is actually a *development* request or if it
>>> could also be solved at the "user" level.
>>> 
>>> As Werner showed in https://github.com/jperon/lyluatex/issues/268
>>> (https://github.com/jperon/lyluatex/issues/268) there is an issue with
>>> the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT
>>> this is something inherent in the lilypond-book handling which should
>>> also be visible in any lilypond-book scores.
>>> 
>>> When compiling with lilypond-book-preamble the score gets sliced in
>>> systems, and each system is *additionally cropped*. I have never
>>> understood the commands in that file so I don't know in what order
>>> these things happen, I don't even know if that lack of the concept of
>>> a "page" (we only have a sequence of systems now) affects the actual
>>> layout process.
>>> 
>>> Of course you will often want to have the cropped systems, essentially
>>> when including single systems in a text document, or at the top or the
>>> bottom of pages. However, when stacking the resulting systems this
>>> means that the space between systems is inconsistent and generally too
>>> narrow. This can sometimes be alleviated by adding space between the
>>> systems, but sometimes this doesn't help. As Werner's example images
>>> in the issue report linked above show: when a system has much
>>> additional stuff above or below (e.g. marks, text or just legder
>>> lines) this significantly disturbes the vertical spacing.
>>> 
>>> What I would need to achieve - either by providing some modification
>>> of lilypond-book-preamble or as a feature request to be added to
>>> LilyPond - is a compilation mode that behaves like
>>> lilypond-book-preamble *without the vertical cropping* (but with
>>> horizontal cropping). Alternatively (maybe even better) would be
>>> writing an additional aux file stating the amount of space cropped, at
>>> least at the top and bottom but maybe for all four sides. Or the
>>> original image size before cropping. Anything that can be used to
>>> infer the space one should add before and after the system to rebuild
>>> LilyPond's original page layout.
>>> 
>>> Any ideas?
>> 
>> For employing something like TeX, one needs to know the baseline, the
>> top extent, the bottom extent, and the skyline spacing to be used
>> between one system and the next. Then one can pad as necessary when
>> systems are separated by pagebreaks or other material and use the
>> skyline spacing then they aren't. Yes, glue like that can be
>> constructed in TeX while still leaving the page break decisions to TeX.
>> 
>> The main problem we are having with cropping is the implementation of
>> cross staff material which does not count towards skylines and extents.
>> Instead it would need to count towards the upper skyline and extent in
>> its top staff, and towards the bottom skyline and extent in its bottom
>> staff. That way it would not push apart the systems it crosses while
>> still making an impact letting it survive in the bounding boxes.
>
> I see that an issue is that *of course* a PDF including one system
> *has* to cause a problem when two adjacent systems
> overlap. https://github.com/jperon/lyluatex/issues/268#issuecomment-516358134
> and
> https://github.com/jperon/lyluatex/issues/268#issuecomment-516360973
> show contrived examples compiled with and without
> lilypond-book-preamble to demonstrate the problem.
>
> Would there be any way to get LilyPond to produce a number from which
> one can infer the extent by which two adjacent systems should overlap
> or have been drawn apart through the page layout?

Uh, no?  We'd be using them in \score-lines or lilypond-book if they
were available, wouldn't we?  Flexible spacing and skyline-based spacing
only exists internally of LilyPond's page breaker/builder.  Cracking
this open would certainly increase LilyPond's flexibility a lot and
would give the design of custom page layouts a lot more substance.

But this is quite a closed box as of now.

-- 
David Kastrup