On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld <hah...@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 <d...@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 <hah...@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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen