Ghostscript fails with special characters in filename

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Ghostscript fails with special characters in filename

thSoft
Some special characters (e.g. ő or đ) in the output filename cause gs to fail on
OS X (10.5) and Linux (Kubuntu 8.10), under LilyPond 2.12.2 and 2.13.3 also.

Converting to `./ő.pdf'...
`gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
-sOutputFile="./�\x91.pdf" -c .setpdfwrite -f "�\x91.ps"' failed (256)
error: failed files: "�\x91.ly"



_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

v.villenave
2009/8/3 Dénes Harmath <[hidden email]>:
> Some special characters (e.g. ő or đ) in the output filename cause gs to fail on
> OS X (10.5) and Linux (Kubuntu 8.10), under LilyPond 2.12.2 and 2.13.3 also.

Er, I think it fails no matter the filename:
http://code.google.com/p/lilypond/issues/detail?id=811

Regards,
Valentin


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

thSoft
In reply to this post by thSoft
On 2009.08.04., at 15:06, Valentin Villenave wrote:

> Er, I think it fails no matter the filename:
> http://code.google.com/p/lilypond/issues/detail?id=811

> Regards,
> Valentin

No, it otherwise works perfectly on an Intel Mac. It only fails always with the
kind of mentioned characters. (Strangely, similar special characters, like ű or
ê, work).
Is there a workaround for this (e.g. a command-line option to use ps2pdf instead
of gs)?



_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

v.villenave
In reply to this post by v.villenave
2009/8/4 Harmath Dénes <[hidden email]>:
> No. It otherwise works perfectly on an Intel Mac. It only fails always with
> the mentioned characters. (Strangely, similar special characters, like ű or
> ê, work).

Could you run lilypond --verbose on your file? That still looks a lot
like #811; perhaps I'll Fwd it to the ghostscript team.

> Is there a workaround for this (e.g. a command-line option to use ps2pdf
> instead of gs)?

There should be IMO (see the discussion on the tracker page). But we
don't have the resources to implement it right now.

Regards,
Valentin


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

pnorcks
On Sat, Aug 08, 2009 at 03:45:25PM +0200, Valentin Villenave wrote:
> 2009/8/4 Harmath Dénes <[hidden email]>:
> > No. It otherwise works perfectly on an Intel Mac. It only fails always with
> > the mentioned characters. (Strangely, similar special characters, like ű or
> > ê, work).
>
> Could you run lilypond --verbose on your file? That still looks a lot
> like #811; perhaps I'll Fwd it to the ghostscript team.

Also note that Ghostscript 8.70 has been released, which I am
currently using.

Maybe 8.70 final has fixed the problem, as I can't seem to reproduce
this problem here...

-Patrick


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

thSoft
In reply to this post by thSoft
> Could you run lilypond --verbose on your file? That still looks a lot like
#811; perhaps I'll Fwd it to the ghostscript team.

The relevant section of the output of lilypond --verbose (2.12.2):

Converting to `./ő.pdf'...
Invoking `gs   -dSAFER  -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4  -dNOPAUSE -dBATCH -r1200  -sDEVICE=pdfwrite
-sOutputFile="./?\x91.pdf" -c .setpdfwrite -f "?\x91.ps"'...GPL Ghostscript SVN
PRE-RELEASE 8.57 (2007-03-15)
Copyright (C) 2007 artofcode LLC, Benicia, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
WARNING: /Unicode /Decoding resource is not accessible but it is useful for
generating ToUnicode CMap.
Error: /undefinedfilename in (\305\\x91.ps)
Operand stack:

Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push
Dictionary stack:
   --dict:1087/1123(ro)(G)--   --dict:0/20(G)--   --dict:69/200(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript SVN PRE-RELEASE 8.57: Unrecoverable error, exit code 1

`gs   -dSAFER  -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4  -dNOPAUSE -dBATCH -r1200  -sDEVICE=pdfwrite
-sOutputFile="./?\x91.pdf" -c .setpdfwrite -f "?\x91.ps"' failed (256)
error: failed files: "?\x91.ly"


It seems the invocation is incorrect, since issuing the command

gs   -dSAFER  -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4  -dNOPAUSE -dBATCH -r1200  -sDEVICE=pdfwrite
-sOutputFile="./ő.pdf" -c .setpdfwrite -f "ő.ps"

succeeds...

> Maybe 8.70 final has fixed the problem, as I can't seem to reproduce this
problem here...

Unfortunately I couldn't build it on OS X, and MacPorts doesn't have the most
recent version. I'll try it on Linux soon.



_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

Ian Hulin
In reply to this post by pnorcks
I've just been investigating this a bit more and have finally managed to install ghostscript 8.70 on my 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:

GNU LilyPond 2.13.3
Processing `Exsultate.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Solving 1 page-breaking chunks...[1: 1 pages]
Drawing systems...
Layout output to `Exsultate-Allegro-čača.ps'...
Converting to `./Exsultate-Allegro-čača.pdf'...
`gs -q -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"

However if I patch up the failed command line and invoke gs 8.70 from the command line this happens:
$ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./Exsultate-Allegro-čača.pdf" -c .setpdfwrite -f "Exsultate-Allegro-čača.ps"
$
I.e. it works.

Lilypond is still using gs V8.65 as shown by this:
$ lilypond --verbose Exsultate.ly
GNU LilyPond 2.13.3
warning: Relocation: is absolute: argv0=/usr/local/lilypond/usr/bin/lilypond
PATH=/usr/local/lilypond/usr/bin (prepend)
Setting PATH to /usr/local/lilypond/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
warning: Relocation: compile datadir=, new datadir=/usr/local/lilypond/usr/share/lilypond//current
warning: Relocation: framework_prefix=/usr/local/lilypond/usr/bin/..
Setting INSTALLER_PREFIX to /usr/local/lilypond/usr/bin/..
Relocation file: /usr/local/lilypond/usr/bin/../etc/relocate//gs.reloc
warning: no such directory: /usr/local/lilypond/usr/bin/../share/ghostscript/8.65/fonts for GS_FONTPATH
warning: no such directory: /usr/local/lilypond/usr/bin/../share/gs/fonts for GS_FONTPATH
GS_LIB=/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource (prepend)
Setting GS_LIB to /usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource
GS_LIB=/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/lib (prepend)
Setting GS_LIB to /usr/local/lilypond/usr/bin/../share/ghostscript/8.65/lib:/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource
GS_LIB=/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource/Init (prepend)
Setting GS_LIB to /usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource/Init:/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/lib:/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource
Relocation file: /usr/local/lilypond/usr/bin/../etc/relocate//fontconfig.reloc
Setting FONTCONFIG_FILE to /usr/local/lilypond/usr/bin/../etc/fonts/fonts.conf
Setting FONTCONFIG_PATH to /usr/local/lilypond/usr/bin/../etc/fonts
Relocation file: /usr/local/lilypond/usr/bin/../etc/relocate//pango.reloc
Setting PANGO_RC_FILE to /usr/local/lilypond/usr/bin/../etc/pango/pangorc
Setting PANGO_PREFIX to /usr/local/lilypond/usr/bin/../
Setting PANGO_MODULE_VERSION to 1.6.0
Relocation file: /usr/local/lilypond/usr/bin/../etc/relocate//guile.reloc
GUILE_LOAD_PATH=/usr/local/lilypond/usr/bin/../share/guile/1.8 (prepend)
Setting GUILE_LOAD_PATH to /usr/local/lilypond/usr/bin/../share/guile/1.8
PATH=/usr/local/lilypond/usr/bin/../bin (prepend)
Setting PATH to /usr/local/lilypond/usr/bin/../bin:/usr/local/lilypond/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Setting GUILE_MIN_YIELD_1 to 65
Setting GUILE_MIN_YIELD_2 to 65
Setting GUILE_MIN_YIELD_MALLOC to 65
Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760
Setting GUILE_MAX_SEGMENT_SIZE to 104857600

LILYPOND_DATADIR="/usr/share/lilypond/2.13.3"
LOCALEDIR="/usr/share/locale"

Effective prefix: "/usr/local/lilypond/usr/share/lilypond/current"
FONTCONFIG_FILE="/usr/local/lilypond/usr/bin/../etc/fonts/fonts.conf"
FONTCONFIG_PATH="/usr/local/lilypond/usr/bin/../etc/fonts"
GS_LIB="/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource/Init:/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/lib:/usr/local/lilypond/usr/bin/../share/ghostscript/8.65/Resource"
GUILE_LOAD_PATH="/usr/local/lilypond/usr/bin/../share/guile/1.8"
PANGO_RC_FILE="/usr/local/lilypond/usr/bin/../etc/pango/pangorc"
PANGO_PREFIX="/usr/local/lilypond/usr/bin/../"
PATH="/usr/local/lilypond/usr/bin/../bin:/usr/local/lilypond/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
[/usr/local/lilypond/usr/share/lilypond/current/scm/lily.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/file-cache.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-event-classes.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-music-types.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/output-lib.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/c++.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/chord-ignatzek-names.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/chord-entry.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/chord-generic-names.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/stencil.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/markup.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/music-functions.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/part-combiner.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/autochange.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-music-properties.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/auto-beam.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/chord-name.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/parser-ly-from-scheme.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/ly-syntax-constructors.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-context-properties.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/translation-functions.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/script.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/midi.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/layout-beam.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/parser-clef.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/layout-slur.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/font.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/encoding.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/flag-styles.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/fret-diagrams.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/harp-pedals.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/predefined-fretboards.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-markup-commands.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-grob-properties.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-grobs.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-grob-interfaces.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/define-stencil-commands.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/titling.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/paper.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/backend-library.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/x11-color.scm]
[/usr/local/lilypond/usr/share/lilypond/current/scm/safe-lily.scm]
Initializing FontConfig...
adding font directory: /usr/local/lilypond/usr/share/lilypond/current/fonts/otf
adding font directory: /usr/local/lilypond/usr/share/lilypond/current/fonts/type1
Building font database.

Processing `Exsultate.ly'
Parsing...
[/usr/local/lilypond/usr/share/lilypond/current/ly/init.ly
 [/usr/local/lilypond/usr/share/lilypond/current/ly/declarations-init.ly
  [/usr/local/lilypond/usr/share/lilypond/current/ly/markup-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/music-functions-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/toc-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/nederlands.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/drumpitch-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/chord-modifiers-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/script-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/scale-definitions-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/grace-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/midi-init.ly
   [/usr/local/lilypond/usr/share/lilypond/current/ly/performer-init.ly]]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/paper-defaults-init.ly
   [/usr/local/lilypond/usr/share/lilypond/current/ly/titling-init.ly]]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/engraver-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/dynamic-scripts-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/spanners-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/property-init.ly]
  [/usr/local/lilypond/usr/share/lilypond/current/ly/predefined-fretboards-init.ly]]
 [Exsultate.ly
  [/usr/local/lilypond/usr/share/lilypond/current/ly/english.ly]
Interpreting music...
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf]
elapsed time: 0.14 seconds
Element count 357 (spanners 49)
Preprocessing graphical objects...
Grob count 529
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-11.otf]
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-13.otf]
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-14.otf]
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-16.otf]
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-18.otf]
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-23.otf]
[century_schoolbook_l_bold_3.865234375]
[century_schoolbook_l_3.865234375]
[century_schoolbook_l_bold_6.1357421875]
[century_schoolbook_l_bold_4.337890625]
[century_schoolbook_l_bold_3.443359375]
Solving 1 page-breaking chunks...[1: 1 pages]
Drawing systems...
Element count 256

[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/aybabtu.otf]
Layout output to `Exsultate-Allegro-čača.ps'...
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/CenturySchL-Bold.otf]
[/usr/local/lilypond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf][/usr/local/lilypond/usr/share/lilypond/current/ps/music-drawing-routines.ps]
[/usr/local/lilypond/usr/share/lilypond/current/ps/lilyponddefs.ps]
Converting to `./Exsultate-Allegro-čača.pdf'...
Invoking `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"'...GPL Ghostscript SVN PRE-RELEASE 8.65 (2009-02-04)
Copyright (C) 2009 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefinedfilename in (Exsultate-Allegro-\304\\x8da\304\\x8da.ps)
Operand stack:

Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push
Dictionary stack:
   --dict:1150/1684(ro)(G)--   --dict:0/20(G)--   --dict:70/200(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript SVN PRE-RELEASE 8.65: Unrecoverable error, exit code 1

`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, or is Lilypond generating a command line with corrupted characters which ghostscript then chokes on?

Is this worth a bug tracker, Valentin?

Cheers,

Ian

 

Patrick McCarty-3 wrote
On Sat, Aug 08, 2009 at 03:45:25PM +0200, Valentin Villenave wrote:
> 2009/8/4 Harmath Dénes <harmathdenes@gmail.com>:
> > No. It otherwise works perfectly on an Intel Mac. It only fails always with
> > the mentioned characters. (Strangely, similar special characters, like ű or
> > ê, work).
>
> Could you run lilypond --verbose on your file? That still looks a lot
> like #811; perhaps I'll Fwd it to the ghostscript team.

Also note that Ghostscript 8.70 has been released, which I am
currently using.

Maybe 8.70 final has fixed the problem, as I can't seem to reproduce
this problem here...

-Patrick


_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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, [hidden email], 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-----


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

v.villenave
2009/8/20 Reinhold Kainhofer <[hidden email]>:
> So, basically, lilypond messes up the proper UTF-8 encoding of the external
> utility calls.

OK, that is now in the tracker as
http://code.google.com/p/lilypond/issues/detail?id=832

Regards,
Valentin


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

Reinhold Kainhofer
In reply to this post by Reinhold Kainhofer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Donnerstag, 20. August 2009 10:48:09 schrieb Reinhold Kainhofer:
> 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...
[...]
> So, basically, lilypond messes up the proper UTF-8 encoding of the external
> utility calls.

Hmm, it seems that it is actually guile's fault:
guile> (simple-format #f "~asdfasdf" "ĉâ")
"�\x89âsdfasdf"
guile> (simple-format #f "~a b âĉ" "ĉâ")
"�\x89â b â�\x89"
guile> "âĉ"
"â�\x89"

To me this seems like guile is not able to properly handle wide UTF-8
characters properly and messes up the wide characters.

Cheers,
Reinhold

- --
- ------------------------------------------------------------------
Reinhold Kainhofer, [hidden email], 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)

iD8DBQFKjRZ0TqjEwhXvPN0RAuHSAJ4z32tPuwfQpf8Q1d4tcLUodKw4VQCgnDHB
ZvDLuRb4vrkdnxvhOHhx6vY=
=nTcp
-----END PGP SIGNATURE-----


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

pnorcks
On 2009-08-20, Reinhold Kainhofer wrote:

> Am Donnerstag, 20. August 2009 10:48:09 schrieb Reinhold Kainhofer:
> > 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...
> [...]
> > So, basically, lilypond messes up the proper UTF-8 encoding of the
> > external utility calls.
>
> Hmm, it seems that it is actually guile's fault:
> guile> (simple-format #f "~asdfasdf" "ĉâ")
> "�\x89âsdfasdf"
> guile> (simple-format #f "~a b âĉ" "ĉâ")
> "�\x89â b â�\x89"
> guile> "âĉ"
> "â�\x89"
>
> To me this seems like guile is not able to properly handle wide UTF-8
> characters properly and messes up the wide characters.
I've been following the Guile mailing lists recently, and it sounds
like UTF-8 handling will be improved in the next stable release.

In the meantime, does this patch work?


Thanks,
Patrick

_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond

0001-Fix-832.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

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

Am Donnerstag, 20. August 2009 11:37:55 schrieb Patrick McCarty:

> On 2009-08-20, Reinhold Kainhofer wrote:
> > Am Donnerstag, 20. August 2009 10:48:09 schrieb Reinhold Kainhofer:
> > > 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...
> >
> > [...]
> >
> > > So, basically, lilypond messes up the proper UTF-8 encoding of the
> > > external utility calls.
> >
> > Hmm, it seems that it is actually guile's fault:
> > guile> (simple-format #f "~asdfasdf" "ĉâ")
> > "�\x89âsdfasdf"
> > guile> (simple-format #f "~a b âĉ" "ĉâ")
> > "�\x89â b â�\x89"
> > guile> "âĉ"
> > "â�\x89"
> >
> > To me this seems like guile is not able to properly handle wide UTF-8
> > characters properly and messes up the wide characters.
>
> I've been following the Guile mailing lists recently, and it sounds
> like UTF-8 handling will be improved in the next stable release.
>
> In the meantime, does this patch work?

Yes, using ly:format instead of simple-format works here.

Cheers,
Reinhold
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, [hidden email], 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)

iD8DBQFKjRvJTqjEwhXvPN0RAjAoAJ9Bhnh6ik5cxtv9wsdHPGRoOCSF+gCfWH3Z
0C+7NTi60/TAh3dzkw0MRq4=
=o4ip
-----END PGP SIGNATURE-----


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

Reinhold Kainhofer
Am Donnerstag, 20. August 2009 11:47:52 schrieb Reinhold Kainhofer:

> Am Donnerstag, 20. August 2009 11:37:55 schrieb Patrick McCarty:
> > On 2009-08-20, Reinhold Kainhofer wrote:
> > > To me this seems like guile is not able to properly handle wide UTF-8
> > > characters properly and messes up the wide characters.
> >
> > I've been following the Guile mailing lists recently, and it sounds
> > like UTF-8 handling will be improved in the next stable release.
> >
> > In the meantime, does this patch work?
>
> Yes, using ly:format instead of simple-format works here.
Of course, the same change needs to be done to the ps->png conversion. Patch
attached.

Cheers,
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, [hidden email], 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

_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond

0006-Use-lilypond-s-string-formating-so-that-wide-utf-8-c.patch (1K) Download Attachment
signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

pnorcks
On 2009-08-20, Reinhold Kainhofer wrote:

> Am Donnerstag, 20. August 2009 11:47:52 schrieb Reinhold Kainhofer:
> > Am Donnerstag, 20. August 2009 11:37:55 schrieb Patrick McCarty:
> > > On 2009-08-20, Reinhold Kainhofer wrote:
> > > > To me this seems like guile is not able to properly handle wide UTF-8
> > > > characters properly and messes up the wide characters.
> > >
> > > I've been following the Guile mailing lists recently, and it sounds
> > > like UTF-8 handling will be improved in the next stable release.
> > >
> > > In the meantime, does this patch work?
> >
> > Yes, using ly:format instead of simple-format works here.
>
> Of course, the same change needs to be done to the ps->png
> conversion. Patch attached.

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.


-Patrick


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

Ian Hulin
Patrick McCarty wrote:

> On 2009-08-20, Reinhold Kainhofer wrote:
>  
>> Am Donnerstag, 20. August 2009 11:47:52 schrieb Reinhold Kainhofer:
>>    
>>> Am Donnerstag, 20. August 2009 11:37:55 schrieb Patrick McCarty:
>>>      
>>>> On 2009-08-20, Reinhold Kainhofer wrote:
>>>>        
>>>>> To me this seems like guile is not able to properly handle wide UTF-8
>>>>> characters properly and messes up the wide characters.
>>>>>          
>>>> I've been following the Guile mailing lists recently, and it sounds
>>>> like UTF-8 handling will be improved in the next stable release.
>>>>
>>>> In the meantime, does this patch work?
>>>>        
>>> Yes, using ly:format instead of simple-format works here.
>>>      
>> Of course, the same change needs to be done to the ps->png
>> conversion. Patch attached.
>>    
>
> 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.

    * The patches fix 90% of the back-end crashes for pdf and png (do we
      need another for svg, by the way?)

    * You've identified a rare case which needs a fix to some pretty
      basic code.
    * 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.

Even if we don't do the last bit, we could go with Rheinhold's patch and
document the restriction.  It certainly fixes the problem well enough
for my purposes in tracker 714.

Cheers,
Ian


From c69fad382e5b5d518c82c798531c9048768cb81e Mon Sep 17 00:00:00 2001
From: Ian Hulin <ian@nanny-ogg.(none)>
Date: Fri, 21 Aug 2009 16:44:23 +0100
Subject: [PATCH] Issue 832 Wrong UTF-8 encoded filenames passed to gs
 1. Change simple-format calls to use ly:format
 2. Change "~S" directives to "-a"
 3. Defend against non-alphanumeric chars and quotes in output file-name
 supplied by user.

---
 scm/backend-library.scm |   17 +++++++++--------
 scm/ps-to-png.scm       |   11 ++++++-----
 2 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/scm/backend-library.scm b/scm/backend-library.scm
index 3a4ccab..c86490d 100644
--- a/scm/backend-library.scm
+++ b/scm/backend-library.scm
@@ -75,18 +75,19 @@
   (search-executable '("gs")))
   
 (define-public (postscript->pdf paper-width paper-height name)
-  (let* ((pdf-name (string-append
-    (dir-basename name ".ps" ".eps")
+  (let* ((filtered-name (string-regexp-substitute "[^-[:alnum:]]" "_" name))
+        (pdf-name (string-append
+    (dir-basename filtered-name ".ps" ".eps")
     ".pdf"))
- (is-eps (string-match "\\.eps$" name))
+ (is-eps (string-match "\\.eps$" filtered-name))
  (paper-size-string (if is-eps
  "-dEPSCrop"
  (ly:format "-dDEVICEWIDTHPOINTS=~$\
  -dDEVICEHEIGHTPOINTS=~$"
  paper-width paper-height)))
 
- (cmd (simple-format #f
-      "~a\
+ (cmd (ly:format
+"~a\
  ~a\
  ~a\
  ~a\
@@ -95,9 +96,9 @@
  -dBATCH\
  -r1200\
  -sDEVICE=pdfwrite\
- -sOutputFile=~S\
+ -sOutputFile=~a\
  -c .setpdfwrite\
- -f ~S\
+ -f ~a\
 "
       (search-gs)
       (if (ly:get-option 'verbose) "" "-q")
@@ -107,7 +108,7 @@
   "-dSAFER")
       paper-size-string
       pdf-name
-      name)))
+      filtered-name)))
     ;; The wrapper on windows cannot handle `=' signs,
     ;; gs has a workaround with #.
     (if (eq? PLATFORM 'windows)
diff --git a/scm/ps-to-png.scm b/scm/ps-to-png.scm
index cb20163..019c2de 100644
--- a/scm/ps-to-png.scm
+++ b/scm/ps-to-png.scm
@@ -108,7 +108,8 @@
       ((string-contains format-str "jpeg") "jpeg")
       (else
        (ly:error "Unknown pixmap format ~a" pixmap-format))))
-  (base (dir-basename ps-name ".ps" ".eps"))
+  (ps-filename (string-regexp-substitute "[^-[:alnum:]]" "_" ps-name))
+  (base (dir-basename ps-filename ".ps" ".eps"))
   (png1 (format "~a.~a" base extension))
   (pngn (format  "~a-page%d.~a" base extension))
   (page-count (ps-page-count ps-name))
@@ -120,16 +121,16 @@
        (format #f "-dDEVICEWIDTHPOINTS=~,2f -dDEVICEHEIGHTPOINTS=~,2f"
        page-width page-height)
        "-dEPSCrop"))
-  (cmd (format #f "~a\
+  (cmd (ly:format "~a\
  ~a\
  ~a\
  -dGraphicsAlphaBits=4\
  -dTextAlphaBits=4\
  -dNOPAUSE\
  -sDEVICE=~a\
- -sOutputFile=~S\
- -r~S\
- ~S\
+ -sOutputFile=~a\
+ -r~a\
+ ~a\
  -c quit"
        (search-gs)
        (if be-verbose "" "-q")
--
1.6.0.4


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

pnorcks
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


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

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

Am Freitag, 21. August 2009 23:20:12 schrieb Patrick McCarty:
> On 2009-08-21, Ian Hulin wrote:
> >    * 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.

It's not so rare, even a file name "a b.ly" broke with the old patch... And
with Ians updated patch, this would result in a_b.ps as output file...

> 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.

Actually, I've now implemented a basic ~s formatting placeholder for
ly:format, which wraps its argument in double quotes and escapes all
backslashes and double quotes. I don't think we need/should print all other
chars as \x..., should we?

Patch can be found in Rietvield:
http://codereview.appspot.com/109070

This works also with pathologic file names like:
a b.ly
b'c.ly
c"d.ly
d'e".ly
e"f'.ly
f\"g.ly
f\"g.pdf
g\'h.ly

Okay to apply.

Cheers,
Reinhold

PS: The patch needs the latest master, because I just fixed an endless loop:
replace_all (&str, "\"", "\\\") would never terminate!
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, [hidden email], 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)

iD8DBQFKjxzxTqjEwhXvPN0RApn+AKCysACddVKDBHDdVkd40LgIOPY/9wCgyinb
+BjTNp4hiWQXHHtqTqe5gV0=
=TPm9
-----END PGP SIGNATURE-----


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

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

Am Samstag, 22. August 2009 00:17:19 schrieb Reinhold Kainhofer:
> This works also with pathologic file names like:
> a b.ly
> b'c.ly
> c"d.ly
> d'e".ly
> e"f'.ly
> f\"g.ly
> f\"g.pdf
> g\'h.ly

I just realized that we have no regression tests to check filename handling.
I.e. We don't catch things that break processing of any of these filenames
(containing spaces, quotes, or other special characters)...

Should we add some test cases to input/regression/ ?

Cheers,
Reinhold
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, [hidden email], 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)

iD8DBQFKjyG8TqjEwhXvPN0RAhq5AJ0cHRswbcNLAOcYepmi/kPa5KwGZQCdEC2B
9BDy20jJ6WXK2KxHhPe0oe0=
=c+2z
-----END PGP SIGNATURE-----


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Ghostscript fails with special characters in filename

Ian Hulin
In reply to this post by pnorcks
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
>
> Can you prepare a revised patch?  I'll apply it for you if it looks
> good.
>
If I can figure out what I need to do in git . . .

Cheers,
Ian


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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, [hidden email], 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-----


_______________________________________________
bug-lilypond mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
12