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
signature.asc
Description: This is a digitally signed message part
