Some weird alignment issues when using a custom header

[rpspringuel]

I've got some weird alignment issues when using a custom header. The below project shows the problem on the second score (where the header field that usually appears on the left has been commented out).

test.zip

This is new with LilyPond 2.24. The code worked fine before upgrading my LilyPond (and lyluatex) versions.

Version information is as follows: LyLuaTeX: 1.1.3 LuaTex: Version 1.15.0 (TeX Live 2022) OS: macOS 12.6.3 Lilypond: 2.24.1 (running Guile 2.2)

[jperon]

There is no change from lyluatex: the temporary files it produces (and we can see better by adding debug option to lyluatex package) are identical. But the same code doesn’t give the same result with 2.22 and 2.24: 2.24 introduces a page break between header and score. I don’t know the reason: perhaps it comes from changes in the Guile interpreter? I don’t master Scheme at all, but if I don’t mistake, the interpreter changed between both versions. pdf.zip

[rpspringuel]

Looking at those files, it appears to be something in lilypond-book-preamble.ly that's inserting the page break. I guess I need to take that to the LilyPond user mailing list.

[rpspringuel]

Reply from LilyPond user Jean About Samra:

This change was on purpose.

lilypond-book-preamble.ly arranges so that LilyPond's notion of pages is changed to make each system or markup a page of its own (except explicit \books).

In 2.22, lilypond-book sets the EPS backend to be used, and the EPS backend caused two things:

• Separate-page output: one file "document-pagenumber.pdf" per page. Since lilypond-book-preamble.ly also turns systems into pages, that effectively means one page per system.

• Tall-page output: the main "document.pdf" output file is just all pages squashed together.

In 2.24, it doesn't do that anymore. It mostly makes the “system as page” setting. Furthermore, the EPS backend has been removed in favor of separate options:

• use -dseparate-page-formats=pdf if you want to get one output file per page (or per system if also using lilypond-book-preamble.ly),

• use -dtall-page-formats=pdf if you want to get squashed pages

So this is what caused the change in outputs, but I'm not seeing the connection to my problem. I don't think it's the page break that's causing the problem.

In my original test document, there are two scores which are almost identical except that one has a header with text at both ends of the line and the other only has text on the right side. The files generated by LilyPond are otherwise identical and yet only one score is pushed way off to the right by lyluatex. Indeed, looking more closely at the result, it's pushed by exactly the amount of whitespace on the left side of the header file. Why does a header which is right aligned (and thus have whitespace on the left hand side) cause the score to be pushed to the right by the width of that whitespace? It strikes me like something is going wrong with the bounding box calculations.

[rpspringuel]

I'm playing around with this and have discovered that the problem is in the protrusion calculation. If I force h_offset in line 310 to 0, then the score is inserted "correctly." I'll need to play around some more to see if I can identify where the protrusion calculation is going wrong, but I'm out of time for the day, so I'm simply recording my findings thus far now.

[rpspringuel]

Okay, after further investigation I've discovered the connection between the change in the LilyPond output and what's happening.

For the purposes of this example, I've been using a score, which when compiled produces 3 lines: Line 1 is a header which has text flush right Line 2 is the first line of music Line 3 is the second (and last) line of music.

Under these circumstances I get the following files from this score in tmp-ly:

<hashnumber>-1.eps
<hashnumber>-2.eps
<hashnumber>-3.eps
<hashnumber>.eps
<hashnumber>-1-eps-converted-to.pdf
<hashnumber>-2-eps-converted-to.pdf
<hashnumber>-3-eps-converted-to.pdf
<hashnumber>.pdf
<hashnumber>.bbox
<hashnumber>.log
<hashnumber>.ly

Of these, only <hashnumber>.eps and <hashnumber>.pdf are used in the bounding box calculations. For these, the eps bounding box looks normal (its left extent is 0). The pdf bounding box, however, gives a high non-zero value for the left extent which is then propagated through the calculations.

Looking inside the pdf, I note that this pdf has 3 pages (1 per line). Thus the gs command returns 3 pairs of lines:

%%BoundingBox: 206 605 310 612
%%HiResBoundingBox: 206.765994 605.195982 309.419991 611.981981
%%BoundingBox: 0 561 310 612
%%HiResBoundingBox: 0.000141 561.977983 309.617991 611.981981
%%BoundingBox: 0 562 310 612
%%HiResBoundingBox: 0.000141 562.877983 309.617991 611.981981

Each pair corresponds to a single page. As you can see, the bounding box is significantly different for the first page (the header) than for the other two pages (the music). However, it's that first page which is used for the protrusion calculation (since only the first matching line gets read in box_parse.

So, how to fix? The simplest fix I've found is to add -dtall-page-formats=pdf to the options for LilyPond. With this option, <hashnumber>.pdf has only one page with all the music on it and thus should behave more like how things were before the LilyPond change. I'm going to submit a PR with that change.