|
From: | N. Andrew Walsh |
Subject: | Re: ghostscript fails on pdf generation |
Date: | Wed, 7 Jun 2017 15:54:26 +0200 |
…because of your second illustration. gs fails early on becauseOn 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
"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/ The second problem looks as if the caller of gs is not protecting theFontmap, pdf output
> works in both console and frescobaldi.
>
> So, is this a bug/defect somewhere in frescobaldi/lilypond/ghostscript? If
> so, which?
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.
[Prev in Thread] | Current Thread | [Next in Thread] |