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

[Jonas Hahnfeld]

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