Re: lilypond-book-preamble and cropping

[Urs Liska]

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?

Urs

> 
> --
> David Kastrup