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: Fri, 19 Jun 2020 12:50:47 +0200
User-agent: Evolution 3.36.3

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.

Jonas

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


reply via email to

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