Re: ghostscript fails on pdf generation

[N. Andrew Walsh]

Hi List,

this error has cropped up again for me. I'll summarize briefly:

compiling a document within frescobaldi (3.0.0) and lilypond-2.19.61 fails with gs error 256. However, this only fails on my laptop, not my main machine (which is running the same versions). 

running the failing gs command on the temp file from a console (ie, copying the failed gs command) results in success. Both laptop and desktop are running the same version of ghostscript. 

On the laptop, SVG display fails with an error about missing PyQt5 Webkit. 

Editing the /usr/share/ghostscript/9.20/Resource/Init/Fontmap file to comment out the line about local fontmaps results in successful compilation and display.

Some questions: 

shouldn't a locally installed version of package lilypond not be relying on my system ghostscript, instead using its own? 

If lilypond is using the system ghostscript, is there a way to get lilypond to ignore that like about Fontmap.local?

Thanks for the help,

A

On Sat, Feb 25, 2017 at 7:11 PM, David Wright <address@hidden> wrote:

On Sat 25 Feb 2017 at 13:06:02 (+0100), N. Andrew Walsh wrote:
> Hi List,
>
> so, I did some digging regarding this error I've been getting with pdf
> output (see below). I found this note to lilypond-users from two years ago:
> https://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00932.html
>
> The money line is to comment out the last line of
> /usr/share/ghostscript/[$GS_VERSION]/Resource/Init/Fontmap,
> which reads:
>
> (Fontmap.local) .runlibfileifexists
>
> When I replaced that line with:
> %(Fontmap.local) .runlibfileifexists
>
> pdf output worked correctly with lilypond/frescobaldi.
>
> Some further information:
> Before this workaround, console output returned the following when running
> the same command from console that was failing in frescobaldi:
>
> $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> -sOutputFile=lamento.pdf -c.setpdfwrite -f/tmp/lilypond-3iqFdT
> GPL Ghostscript 9.20: Can't embed the complete font LinLibertineO as it is
> too large, embedding a subset.
> GPL Ghostscript 9.20: Can't embed the complete font LinLibertineOI as it is
> too large, embedding a subset.
> GPL Ghostscript 9.20: Can't embed the complete font LinLibertineOB as it is
> too large, embedding a subset.
> $
>
> If, however, the intended output filename has whitespaces, I get the
> following error:
>
>  $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> -sOutputFile=Reinhold Urmetzer - Lamento di Achille.pdf -c.setpdfwrite
> -f/tmp/lilypond-DDb0P7
> Error: /undefinedfilename in (Urmetzer)
> Operand stack:
>
> Execution stack:
>    %interp_exit   .runexec2   --nostringval--   --nostringval--
> --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
> --nostringval--   false   1   %stopped_push
> Dictionary stack:
>    --dict:1211/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--
> Current allocation mode is local
> Last OS error: No such file or directory
> GPL Ghostscript 9.20: Unrecoverable error, exit code 1
> $
>
> So, to review:
> if the filename has spaces, gs output will fail both in frescobaldi and
> from console

…because of your second illustration. gs fails early on because
"Urmetzer" is a non-option and therefore expected to be a Ghostscript
program for interpretation.

> if the filename does not have spaces, output fails in frescobaldi, and also
> running lilypond from console, but not running the last 'gs' command from
> console

…because of your first illustration. gs fails later on because of the
font overcapacity.

> if that last line about Fontmap.local is commented out
> in /usr/share/ghostscript/[$GS_VERSION]/Resource/Init/Fontmap, pdf output
> works in both console and frescobaldi.
>
> So, is this a bug/defect somewhere in frescobaldi/lilypond/ghostscript? If
> so, which?

The second problem looks as if the caller of gs is not protecting the
spaces in the filename. Some interesting things can happen by chance
with those filenames. If you put
... -sOutputFile="good output.pdf" -c.setpdfwrite -f/tmp/somefile
everything works as normal. So does
... -sOutputFile=good\ output.pdf -c.setpdfwrite -f/tmp/somefile
and so does
... -sOutputFile=good /tmp/somefile -c.setpdfwrite

However, if you put
... -sOutputFile=good output.pdf -c.setpdfwrite -f/tmp/somefile
and there happens to be a file called output.pdf, gs will happily
give you a PDF called "good" containing output.pdf followed by
the converted /tmp/somefile.

You could test that "in the field", as it were, by running a
file with a single space in its name, "foo bar", and leaving
a bar.pdf file in the output directory. The result should be
a PDF file called foo containing bar.pdf followed by the
LilyPond output.

I can't help with the font problem, sorry.

Cheers,
David.