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

[Han-Wen Nienhuys]

On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
>
> Am Freitag, den 19.06.2020, 12:18 +0200 schrieb Han-Wen Nienhuys:
> > On Fri, Jun 19, 2020 at 12:11 PM David Kastrup <dak@gnu.org> wrote:
> > > Jonas Hahnfeld via Discussions on LilyPond development
> > > <lilypond-devel@gnu.org> writes:
> > >
> > > > Am Freitag, den 19.06.2020, 11:47 +0200 schrieb Han-Wen Nienhuys:
> > > > > On Thu, Jun 18, 2020 at 7:45 PM Jonas Hahnfeld <hahnjo@hahnjo.de> 
> > > > > wrote:
> > > > > > Am Donnerstag, den 18.06.2020, 11:21 -0600 schrieb Carl Sorensen:
> > > > > > > is it the difference between an output .ps file and an output 
> > > > > > > .eps file?
> > > > > >
> > > > > > No, broken.ps file is only the driver for Ghostscript:
> > > > > > mark /OutputFile (broken.pdf) (pdfwrite) finddevice putdeviceprops
> > > > > > setdevice (broken.eps) run
> > > > > >
> > > > > > Both ways use the same broken.eps file:
> > > > > > %!PS-Adobe-2.0 EPSF-2.0
> > > > > >
> > > > > > Yes, it's empty except for that line.
> > > > >
> > > > > That doesn't look like an EPS file that LilyPond should be producing.
> > > > >
> > > > > Let me do some research today where that comes from.
> > > >
> > > > No, this is the only smallest possible EPS file that shows the problem.
> > > > I'm attaching the real file from LilyPond to this message, but the
> > > > important part is probably that it contains no graphical objects.
> > >
> > > That triggers some memory: this may not have anything to do with
> > > autorotation?  That GhostScript decides on landscape orientation
> > > unexpectedly or so?
> >
> > Good sleuthing. AutoRotatePages is a device parameter, so it gets
> > overwritten by the defaults in the broken version.
> >
> > Let me try what happens if we add it to the driver script.
>
> 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.

OK. Just for completeness,

$ gs -dNOSAFER -dNOPAUSE -dBATCH -dEPSCrop -dAutoRotatePages=/None
-dPrinted=false -sDEVICE=pdfwrite -sOutputFile=broken.pdf -c
"currentdevice getdeviceprops pstack clear (broken.eps) run" >
working-params
$ diff -u working-params broken-params
--- working-params 2020-06-19 12:58:12.583854270 +0200
+++ broken-params 2020-06-19 12:44:03.069918170 +0200
@@ -326,11 +326,11 @@
 /Colors
 (pdfwrite)
 /Name
-[595.0 842.0]
+[612.0 792.0]
 /.MediaSize
 [0.0 0.0 0.0 0.0]
 /.HWMargins
-[5950 8420]
+[6120 7920]
 /HWSize
 8
 /TextKPreserve
@@ -404,7 +404,7 @@
 /HWResolution
 /DeviceRGB
 /ProcessColorModel
-[595.0 842.0]
+[612.0 792.0]
 /PageSize
 /pdfwrite
 /OutputDevice

adding these to the broken file,

$ cat broken.ps
mark /AutoRotatePages /None /OutputFile (broken.pdf)
/HWSize
[6120 7920]
/.MediaSize
[612.0 792.0]
/PageSize
[612.0 792.0]
(pdfwrite) finddevice putdeviceprops setdevice
currentdevice getdeviceprops pstack clear
(broken.eps) run

$ gs -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH -dEPSCrop
-dAutoRotatePages=/None -dPrinted=false broken.ps > broken-params
..

(no change, the page size stays at its previous value)

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen