Re: Ghostscript fails with special characters in filename

[Patrick McCarty]

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.

Can you prepare a revised patch?  I'll apply it for you if it looks
good.


Thanks,
Patrick