Re: lilypond-book-preamble and cropping
"Urs Liska" writes: > 30. Juli 2019 11:16, "David Kastrup" schrieb: > >> "Urs Liska" 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
Re: lilypond-book-preamble and cropping
30. Juli 2019 11:16, "David Kastrup" schrieb: > "Urs Liska" 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
Re: lilypond-book-preamble and cropping
"Urs Liska" 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book-preamble and cropping
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? Thanks Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
