Re: Ghostscript fails with special characters in filename

[Reinhold Kainhofer]

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

Am Samstag, 22. August 2009 15:57:51 schrieb Ian Hulin:
> Hi Patrick, Reinhold,
>
> Patrick McCarty wrote:
> > On 2009-08-21, Ian Hulin wrote:
> >> Patrick McCarty wrote:
> >>> Hmm...
> >>>
> >>> I just realized why the ~S was being used instead of ~a: the ~S allows
> >>> double quotes in the filename, but ~a does not.
> >>>
> >>> So this would fail with your patch:
> >>>
> >>>  $ lilypond \"file\".ly
> >>>
> >>> Even though it is an unlikely filename, ly:format cannot accept it
> >>> using ~a.
> >>>
> >>> Now, I'm having trouble finding an equivalent to ~S to use with
> >>> ly:format; such an option does not seem to exist.  I think we're
> >>> stuck, unless someone can implement an ~S format specifier for
> >>> ly:format.
> >>
> >> Just thinking out loud. .
> >>
> >>    * These patches work round a guile restriction, which they're
> >>      planning to fix.
> >
> > Well, I don't know for certain if the Guile team has fixed *this*
> > particular restriction, namely that "format" cannot handle wide UTF-8
> > characters.
> >
> >>    * The patches fix 90% of the back-end crashes for pdf and png (do we
> >>      need another for svg, by the way?)
> >
> > It's not needed for the SVG backend, since the filename is not being
> > passed to a command.
> >
> >>    * You've identified a rare case which needs a fix to some pretty
> >>      basic code.
> >
> > How do we know it's rare?  I don't think it's worth breaking PDF
> > generation based on an assumption.
> >
> >>    * You could add something like
> >>      (set! filename string-regexp-substitute ("[^-[:alnum:]]" "_"
> >>      filename)) to defend against this, see attached patch - it's
> >>      Rheinhold's patch with some extra code to defend against the case
> >>      you pointed out, changing the file\.pdf to file_.pdf.
> >
> > The real issue is that double quotes are not escaped, so in your
> > patch, you should use
> >
> >   (filtered-name (string-regexp-substitute "\"" "\\\"" name))
> >
> > instead.  If you look at the "escape-string" procedure in
> > scm/output-socket.scm, you'll see another place where this technique
> > is used.
>
> Looks to me like it's not quite so straightforward.
> (I'm assuming here we've accepted and are using Reinhold's ly:format
> upgrade to interpret ~S)
> Maybe we need to do something like this pseudocode?
> if (the incoming filename has any " characters)
> then
>       escape all the " characters
>       use the /S directive
> else
>       filter out any problem characters
>       use the /a directive
> endif

Why would we need this? ~s should always be able to run gs without any 
problems. If it's not, that's a bug in the implementation of ~s!

Furthermore, your pseudocode to filter out any "problem characters" will 
terribly break makefiles etc. since the output filename will no longer be 
inputfilename.pdf and thus standard rules like:
%.pdf: %.ly
        lilypond $<
will fail.

Lilypond needs to be able to handle all characters that the OS allows in a 
filename and produce output files that are exactly the same as the input 
filename. Period.

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)

iD8DBQFKkCZRTqjEwhXvPN0RAp8YAJ0ahtW5my+EdRUbe0h+D0b1LVdy5QCdFNWo
B6UP8H2IxIg3cfLc85F/KpY=
=zvNE
-----END PGP SIGNATURE-----