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? Urs > > -- > David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
