lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lilypond-book-preamble and cropping


From: David Kastrup
Subject: Re: lilypond-book-preamble and cropping
Date: Tue, 30 Jul 2019 11:16:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

"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.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]