Thanks; yours is much nicer. Meanwhile, mine is failing for unknown reasons.
How does this thing work? make doc => # Making input/regression/out-www/collated-files.pdf < texi TEX=/home/hanwen/vc/lilypond/scripts/build/xetex-with-options.sh PDFTEX=/home/hanwen/vc/lilypond/scripts/build/xetex-with-options.sh PDFLATEX=/home/hanwen/vc/lilypond/scripts/build/xelatex-with-options.sh \ /home/hanwen/vc/lilypond/scripts/build/run-and-check.sh \ "cd ./out-www; \ texi2pdf --batch \ \ \ -I /home/hanwen/vc/lilypond/input/regression \ \ -o collated-files.tmp.pdf \ collated-files.texi \ < /dev/null" \ "./out-www/collated-files.texi2pdf.log" .. [1][2][3][4 xdvipdfmx:warning: Trying to include PDF file with version (1.7), which is newer than current output PDF setting (1.5). xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161) No output PDF file written. /usr/bin/texi2dvi: /home/hanwen/vc/lilypond/scripts/build/xetex-with-options.sh exited with bad status, quitting. make[1]: *** [/home/hanwen/vc/lilypond/stepmake/stepmake/texinfo-rules.make:85: out-www/collated-files.pdf] Error 1 But, $ cd out-www/ ; TEX=/home/hanwen/vc/lilypond/scripts/build/xetex-with-options.sh PDFTEX=/home/hanwen/vc/lilypond/scripts/build/xetex-with-options.sh PDFLATEX=/home/hanwen/vc/lilypond/scripts/build/xelatex-with-options.sh texi2pdf --batch -I /home/hanwen/vc/lilypond/input/regression -o collated-files.tmp.pdf collated-files.texi => .. 3295 bytes written (see the transcript file for additional information) Output written on collated-files.pdf (1 page). Transcript written on collated-files.log. [hanwen@t460-wlan out-www]$ echo $? 0 On Fri, Jun 19, 2020 at 4:25 PM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > Am Freitag, den 19.06.2020, 15:36 +0200 schrieb Jonas Hahnfeld: > > Am Freitag, den 19.06.2020, 15:11 +0200 schrieb Jonas Hahnfeld: > > > Am Freitag, den 19.06.2020, 14:49 +0200 schrieb Han-Wen Nienhuys: > > > > [hanwen@t460-wlan lilypond]$ qpdf --qdf --object-streams=disable > > > > broken2.pdf /dev/stdout | grep Contents > > > > /Contents 7 0 R > > > > %% Contents for page 1 > > > > [hanwen@t460-wlan lilypond]$ qpdf --qdf --object-streams=disable > > > > broken1.pdf /dev/stdout | grep Contents > > > > > > Looking into the generated source code, this comes from Ghostscript > > > file devices/vector/gdevpdf.c: > > > === > > > /* > > > * The PDF documentation allows, and this code formerly emitted, > > > * a Contents entry whose value was an empty array. Acrobat Reader > > > * 3 and 4 accept this, but Acrobat Reader 5.0 rejects it. > > > * Fortunately, the Contents entry is optional. > > > */ > > > if (page->contents_id != 0) > > > pprintld1(s, "/Contents %ld 0 R\n", page->contents_id); > > > === > > > So it claims omitting the entry is correct, but xdvipdfmx disagrees. > > > This reduces the problem to finding out why contents_id is different > > > for the two invocations... > > > > I think I got it, the magic words are "newpath fill" between setdevice > > and run. This comes from Resource/Init/gs_pdfwr.ps where I noticed the > > following comment: "Note, this may not work if the initial device is > > not pdfwrite". Was suspicious enough to give it a try and my broken.pdf > > is now accepted by xelatex. Let me run this through a full 'make doc'.. > > It passed, I've opened a merge request at: > https://gitlab.com/lilypond/lilypond/-/merge_requests/179 -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
