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

[Han-Wen Nienhuys]

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 <hahnjo@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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen