Re: xdvipdfmx fails with some regtests (“Invalid object”)

[Jonas Hahnfeld]

Am Freitag, den 19.06.2020, 14:49 +0200 schrieb Han-Wen Nienhuys:
> On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld <hahnjo@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