Re: ghostscript fails on pdf generation

[David Wright]

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.