lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jonas Hahnfeld
Subject: Re: xdvipdfmx fails with some regtests (“Invalid object”)
Date: Thu, 18 Jun 2020 19:03:48 +0200
User-agent: Evolution 3.36.3

Am Donnerstag, den 18.06.2020, 00:23 +0200 schrieb Valentin Villenave:
> On 6/17/20, Valentin Villenave <valentin@villenave.net> wrote:
> > `make doc’ has been broken for nearly a week on my system (even with a
> > clean git clone), with the following error:
> > 
> > xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161)
> 
> Git bisect actually tells me that xdvipdfmx started misbehaving from
> the same commit that caused gs issues:
> 
> 017927b4d63c317e1fc450be2537ccc058072538 (HEAD)
>     Author: Han-Wen Nienhuys <hanwenn@gmail.com>
>     Date:   Fri Jun 5 20:36:42 2020 +0200
>     Unify calling convention for command-line and API GS use
> 
> Jonas reverted some parts of that with MR !148, but that particular
> issue was left unaddressed.  That affects xdvipdfmx svn/20190225,
> which is shipped with Fedora 32, and with a more recent build from the
> 2020 texlive release (20200315). (Now, I haven’t been able to
> reproduce it on LilyDev so other libraries may be a factor as well.)
> 
> It already took me many hours to find the eight regtests that trigger
> this, but there are also many snippets and NR ly blocks, which I won’t
> be able to track down :-/

I can reproduce this kind of error with an empty .eps file, I'm
attaching a (very minimal) example. The .ps file mimics the input that
LilyPond passes to Ghostscript since the commit mentioned above.

So the following fails:
$ gs -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH -dEPSCrop -dAutoRotatePages=/None 
-dPrinted=false broken.ps
$ xelatex include.tex
but
$ pdflatex include.tex
succeeds.

Likewise the "old" way of doing
$ gs -dNOSAFER -dNOPAUSE -dBATCH -dEPSCrop -dAutoRotatePages=/None 
-dPrinted=false -sDEVICE=pdfwrite -sOutputFile=broken.pdf broken.eps
$ xelatex include.tex
is fine, so it's likely something between Ghostscript and XeTeX (on
Arch Linux: GS 9.52, TeXlive 2019, xdvipdfmx 20190503).

I think the way forward for now is reverting above commit, even if I
don't really like it. Unless somebody has a really clever idea how to
1) avoid GS producing a broken PDF (if that's the case), or
2) make xelatex accept the PDF produced by GS as described above.

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]