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. _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
