Am Freitag, den 19.06.2020, 14:49 +0200 schrieb Han-Wen Nienhuys: > On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > No changes for me. Please also keep in mind that the same command > > string works via the API interpreter. It could be that this is related > > to processing other files before the "empty" one... > > I'll try to write a small wrapper around the API so we can test outside > > of LilyPond what actually triggers the broken PDF. > > Your hunch is correct. No need to write a wrapper, the following in a > .ly file works if you replace SCM_UNDEFINED with SCM_UNSPECIFIED in > ly:gs-api > > [...] > > [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...
Jonas
signature.asc
Description: This is a digitally signed message part
