Created attachment 7841 [details] PS document generated with lilypond This bug was originally reported to Evince: https://bugzilla.gnome.org/show_bug.cgi?id=650996 It only happens when locale is not C. Error: /invalidfont in definefont
Created attachment 7842 [details] Test case This is a small tes case to reproduce the issue. It uses the pdfwrite device, but the problem is also present when using display device. When called with C locale $ ./pdfwrite-locale PartitionEssaiStaffEspace.ps C GPL Ghostscript 9.01 (2011-02-07) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. When called with a diferent locale (es in my case) $ ./pdfwrite-locale PartitionEssaiStaffEspace.ps es_ES.UTF-8 GPL Ghostscript 9.01 (2011-02-07) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Error: /invalidfont in definefont Operand stack: CenturySchL-Bold --nostringval-- CenturySchL-Bold CenturySchL-Bold --dict:6/20(L)-- Font Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop 1787 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- --dict:1/1(L)-- --nostringval-- 1 %dict_continue 1866 5 5 %oparray_pop Dictionary stack: --dict:1158/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)-- --dict:54/106(ro)(G)-- --dict:8/30(L)-- Current allocation mode is local Current file position is 59524 GPL Ghostscript 9.01: Unrecoverable error, exit code 1
Please submit the Ghostscript command line produced by pdfwrite-locale (with both the C argument and the other one that works).
The command line is the same, something like: gs -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=out.pdf -c .setpdfwrite -f PartitionEssaiStaffEspace.ps and that works with any locale, the problem is when using the libgs API, when setlocale is called. It happens in any gtk application, because gtk_init calls setlocale with NULL to se current system locale. It's not a problem with the pdfwrite device etiher, because it's also reproducible with the display device, I used pdfwrite to make the test case simpler.
Carlos, when you submit a bug, the first step before we can start to find a solution, is to reproduce the problem. We are, in general, very busy with paying customer bugs, so we don't have as much time as we'd like to spend on free user bugs. Therefore, bugs that are hard to reproduce will be less likely to get attention. It would therefore be in your interest to minimise the amount of work we have to do to reproduce the problem. If a bug only shows up when code is called via the gsapi, then provide us with the simplest possible route to reproducing the problem - such as a small example application. Taking the time to give us a clear, coherent, easy to reproduce bug report will pay dividends in terms of the chances of your bug being looked at.
(In reply to comment #0) > This bug was originally reported to Evince: > https://bugzilla.gnome.org/show_bug.cgi?id=650996 Please re-open the downstream bug against evince. I can reproduce this problem using either: LANG=es_ES.UTF-8 gsx 'bugs.ghostscript.com/attachment.cgi?id=7841&action=view' or: LANG=es_ES.UTF-8 evince 'bugs.ghostscript.com/attachment.cgi?id=7841&action=view' gsx needs to have something like this applied. I bet there is a corresponding change needed to be made in evince. -------------------------------------------------------- diff --git a/gs/psi/dxmain.c b/gs/psi/dxmain.c index 2df19e0..556aad6 100644 --- a/gs/psi/dxmain.c +++ b/gs/psi/dxmain.c @@ -30,6 +30,7 @@ #include <unistd.h> #include <fcntl.h> #include <gtk/gtk.h> +#include <locale.h> #define __PROTOTYPES__ #include "ierrors.h" #include "iapi.h" @@ -1093,6 +1094,7 @@ int main(int argc, char *argv[]) /* Gtk initialisation */ gtk_set_locale(); + setlocale(LC_NUMERIC,"POSIX"); use_gui = gtk_init_check(&argc, &argv); /* insert display device parameters as first arguments */ --------------------------------------------------------- Apparently gtk_set_locale() is deprecated. (http://developer.gnome.org/gtk/2.24/gtk-General.html#gtk-set-locale), and probably should be removed. See also: https://mail.gnome.org/archives/gtk-app-devel-list/2000-October/msg00313.html https://mail.gnome.org/archives/gtk-app-devel-list/2000-October/msg00320.html
(In reply to comment #4) > Carlos, when you submit a bug, the first step before we can start to find a > solution, is to reproduce the problem. We are, in general, very busy with > paying customer bugs, so we don't have as much time as we'd like to spend on > free user bugs. Therefore, bugs that are hard to reproduce will be less likely > to get attention. I understand. > It would therefore be in your interest to minimise the amount of work we have > to do to reproduce the problem. I tried it. > If a bug only shows up when code is called via the gsapi, then provide us with > the simplest possible route to reproducing the problem - such as a small > example application. Taking the time to give us a clear, coherent, easy to > reproduce bug report will pay dividends in terms of the chances of your bug > being looked at. The bug was reported to Client API component to make clear it only happens with libgs, I attached a ps file and small example application to reproduce the issue and posted examples of how to run the test application with the output it gives in every case (C and other locale). Please, let me know what else do you need to make it easier for you to fix this bug.
(In reply to comment #5) > (In reply to comment #0) > > This bug was originally reported to Evince: > > https://bugzilla.gnome.org/show_bug.cgi?id=650996 > > Please re-open the downstream bug against evince. I can reproduce this problem > using either: > > LANG=es_ES.UTF-8 gsx 'bugs.ghostscript.com/attachment.cgi?id=7841&action=view' > or: > LANG=es_ES.UTF-8 evince > 'bugs.ghostscript.com/attachment.cgi?id=7841&action=view' > > gsx needs to have something like this applied. I bet there is a corresponding > change needed to be made in evince. > -------------------------------------------------------- > diff --git a/gs/psi/dxmain.c b/gs/psi/dxmain.c > index 2df19e0..556aad6 100644 > --- a/gs/psi/dxmain.c > +++ b/gs/psi/dxmain.c > @@ -30,6 +30,7 @@ > #include <unistd.h> > #include <fcntl.h> > #include <gtk/gtk.h> > +#include <locale.h> > #define __PROTOTYPES__ > #include "ierrors.h" > #include "iapi.h" > @@ -1093,6 +1094,7 @@ int main(int argc, char *argv[]) > > /* Gtk initialisation */ > gtk_set_locale(); > + setlocale(LC_NUMERIC,"POSIX"); > use_gui = gtk_init_check(&argc, &argv); > > /* insert display device parameters as first arguments */ > --------------------------------------------------------- This is not correct, at least not for evince, this would change other strings in the UI that are locale dependent, for example it would use a dot as decimal separator, which is not correct in many locales.
(In reply to comment #7) > This is not correct, at least not for evince, this would change other strings > in the UI that are locale dependent, for example it would use a dot as decimal > separator, which is not correct in many locales. Well, if you can fix it differently, by all means. But does evince use decimals anywhere in the GUI?? Really?? My inline patch was for fixing gsx (in gs/psi/dxmain.c). On my system (gnome 3, but as far as the gtk2 libraries are concerned, gnome 2.28), just removing gtk_set_locale() without adding the setlocale() also works. This is probably the recommended routine if support for gnome system < 2.24 is not needed. If you want a "recently correct" solution to evince, it is probably just removing gtk_set_locale() . gtk_set_locale() is supposedly deprecated and not needed for gnome > 2.24.
(In reply to comment #8) > (In reply to comment #7) > > This is not correct, at least not for evince, this would change other strings > > in the UI that are locale dependent, for example it would use a dot as decimal > > separator, which is not correct in many locales. > > Well, if you can fix it differently, by all means. But does evince use decimals > anywhere in the GUI?? Really?? Yes, in the printing dialog for example, > My inline patch was for fixing gsx (in > gs/psi/dxmain.c). On my system (gnome 3, but as far as the gtk2 libraries are > concerned, gnome 2.28), just removing gtk_set_locale() without adding the > setlocale() also works. This is probably the recommended routine if support for > gnome system < 2.24 is not needed. > > If you want a "recently correct" solution to evince, it is probably just > removing gtk_set_locale() . gtk_set_locale() is supposedly deprecated and not > needed for gnome > 2.24. We don't use gtk_set_locale at all in evince, current system locale is used by default in gtk apps
(In reply to comment #9) > We don't use gtk_set_locale at all in evince, current system locale is used by > default in gtk apps Not even indirectly? There is a setlocale() call in libevdocument3.so.3, which is part of evince-libs . $ nm -D /usr/bin/evince | grep locale U ev_get_locale_dir $ nm -D /usr/lib64/libevdocument3.so.3 | grep locale 000000359d8142e0 T ev_get_locale_dir U g_key_file_get_locale_string U g_locale_to_utf8 U setlocale $ ldd /usr/bin/evince | grep evdocument libevdocument3.so.3 => /usr/lib64/libevdocument3.so.3 (0x000000359d800000) So it appears that evince uses libevdocument3 and libevdocument3 uses setlocale(). and somewhere along the line /usr/lib64/evince/3/backends/libpsdocument.so is loaded, which in turn loads libgs. I suggest you possibly look inside libevdocument3 .
(In reply to comment #10) > (In reply to comment #9) > > We don't use gtk_set_locale at all in evince, current system locale is used by > > default in gtk apps > > Not even indirectly? No. > There is a setlocale() call in libevdocument3.so.3, which > is part of evince-libs . > > $ nm -D /usr/bin/evince | grep locale > U ev_get_locale_dir > $ nm -D /usr/lib64/libevdocument3.so.3 | grep locale > 000000359d8142e0 T ev_get_locale_dir > U g_key_file_get_locale_string > U g_locale_to_utf8 > U setlocale > $ ldd /usr/bin/evince | grep evdocument > libevdocument3.so.3 => /usr/lib64/libevdocument3.so.3 (0x000000359d800000) > > So it appears that evince uses libevdocument3 and libevdocument3 uses > setlocale(). > and somewhere along the line > /usr/lib64/evince/3/backends/libpsdocument.so is loaded, which in turn loads > libgs. > > I suggest you possibly look inside libevdocument3 . The only calls to setlocale are in synctex parser, which is only executed for pdf files and it changes the locale only when needed and it restores the system locale again, see: http://git.gnome.org/browse/evince/tree/cut-n-paste/synctex/synctex_parser.c#n1612 This code doesn't affect postscript files at all.
The description here is not very accurate. The problem *only* occurs with locales where the decimal separator is not ".", as in the example, Spanish, which IIRC uses "," as the decimal separator. This changes the behavior of sscanf() so that it fails to parse numbers with a fractional component in the CFF interpreter. NOTE: I *very* nearly closed this as "works for me" because all the locales I had installed worked just fine - accurate reporting is really important in these cases! Anyway, the problem is fixed in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=850145 by replacing sscanf() with the Ghostscript PS interpreter's own number parsing function.