"Urs Liska" <li...@openlilylib.org> writes: > 30. Juli 2019 11:16, "David Kastrup" <d...@gnu.org> schrieb: > >> "Urs Liska" <li...@openlilylib.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
