Am Freitag, den 19.06.2020, 12:18 +0200 schrieb Han-Wen Nienhuys: > On Fri, Jun 19, 2020 at 12:11 PM David Kastrup <[email protected]> wrote: > > Jonas Hahnfeld via Discussions on LilyPond development > > <[email protected]> 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 <[email protected]> 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. Jonas
signature.asc
Description: This is a digitally signed message part
