Re: Ghostscript fails with special characters in filename

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Donnerstag, 20. August 2009 03:41:57 schrieb ian_hulin:
> I've just been investigating this a bit more and have finally managed to
> install ghostscript 8.70 on my system.

I have ghostscript 8.64 installed on my kubuntu system.

> If I compile a .ly file which will cause a .pdf and .ps file to have 16-bit
> Unicode characters (like čača by setting output-suffix to a string
> containing such characters lilypond barfs when trying to generate the .pdf
> file:

Me too.

> However if I patch up the failed command line and invoke gs 8.70 from the
> command line this happens:

Yes, it works also with gs 8.64 if you pass the input .ps file name in the 
correct encoding.

> `gs  -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> -sOutputFile="./Exsultate-Allegro-�\x8da�\x8da.pdf" -c .setpdfwrite -f
> "Exsultate-Allegro-�\x8da�\x8da.ps"' failed (256)
> error: failed files: "Exsultate.ly"
>
> So, is the failure being caused by using ghostscript V8.65 instead of
> V8.70, 

No.

> or is Lilypond generating a command line with corrupted characters
> which ghostscript then chokes on?

Yes, I think that's the case here. It seems that gs is well able to handle 16-
bit unicode characters, but it needs the correct file name. 

A little more playing around shows this: Calling "lilypond --png ĉacâ.ly" 
prints an error message:  
   Error: /undefinedfilename in (\304\\x89ac\303\242.ps)
As you can see, the high-byte character is written as \x89ac, however, the 
backslash is escaped, which of course makes it an invalid UTF-8 character 
considering the \304 before... 
The same problem of course also happens with the --pdf backend, as the gs call 
of lilypond shows, where the file name is printed as "Exsultate-Allegro-
�\x8da�\x8da.ps"'. The squares with a question mark indicate a modifier for a 
>8-bit UTF character, but the backslash after that is printed verbatim (i.e. 
internally it is escaped, making this character invalid UTF-8 again).

So, basically, lilypond messes up the proper UTF-8 encoding of the external 
utility calls.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKjQ3KTqjEwhXvPN0RAri0AJ9cc9BWbppEjMg7DdPPy6fuzRjEBgCeKvoL
pFD7F1zpep358ec+UjBnPps=
=+UWf
-----END PGP SIGNATURE-----