After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 130814 - Broken PS generation in non-C locales
Broken PS generation in non-C locales
Product: gnome-print
Classification: Deprecated
Component: Postscript backend
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Reported: 2004-01-07 21:10 UTC by Glynn Foster
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6

ps locale generation fix (1.29 KB, patch)
2004-01-07 21:11 UTC, Glynn Foster
none Details | Review
Bogus PS file (16.08 KB, application/postscript)
2004-06-16 17:31 UTC,

Description Glynn Foster 2004-01-07 21:10:33 UTC
Here's a patch from JDS that fixes it, although I notice it does use
setlocale ;)

Comments in the associated bug -

The issue with the pdf is even seen in C locale. "Invalid operator found"

I have created a patch for rectifying the PS generation in some locales. In
patch, LC_NUMERIC should be set to C when printing floating numbers into PS
file, otherwise in some locales where the decimal separater is comma, PS
will be confused.
Comment 1 Glynn Foster 2004-01-07 21:11:14 UTC
Created attachment 23091 [details] [review]
ps locale generation fix
Comment 2 Andreas J. Guelzow 2004-01-08 06:14:52 UTC
I don't think we should play with the locale just to print some
floating point numbers. 
Comment 3 Andreas J. Guelzow 2004-01-08 06:17:24 UTC
To be more specific: Bug 109446 specifically mentions that gnome-print
should never use the not thread-safe setlocale. So the proposed patch
is definitely not the correct way to fix this bug. In fact,
gnome-print has also other places with the same problem, eg. in
Comment 4 Andreas J. Guelzow 2004-01-08 06:23:59 UTC
Can we get one of those invalid postscript files? Preferably a small
one? Created with current cvs HEAD?  gnome_print_ps2_fprintf already
conatains one of those undesirable setlocale calls, so I am not sure
where the invalid decimal separator comes from.
Comment 5 Jody Goldberg 2004-01-08 14:08:22 UTC
The approach in the rest of gnomep-print was to set and reset the
locale for every operation which is damn ugly.  Going forward what I'd
like to do is just adopt a pango-esque scale factor and only ouput

For now it would be helpful to get
1) The locale that failed
2) which application was producing the output
3) any input files necessary for (2)
Comment 6 Morten Welinder 2004-01-08 16:20:49 UTC
We don't output that many floating point values.  We could probably
get away with using a simple "%d.%06d" type of solution.
Comment 7 Andreas J. Guelzow 2004-01-08 16:51:09 UTC
I am in the process of getting rid of those setlocales by using glib's

I don't think we can ever get competely rid of floating point numbers
since we do need to output postscript. 
Comment 8 Andreas J. Guelzow 2004-01-11 07:43:45 UTC
I have changed all the relevant code to be locale independent (ie. no
use of %f in calls to ...printf). So this issue should be resolved in
current cvs HEAD.

Please reopen if you should still find a problem with PS generation in
non-C locale.

Comment 9 2004-06-16 17:25:46 UTC
gnome-print 2.6.1
Debian unstable
Locale set to lt_LT.UTF-8

It seems, that I have found a regression here - I was fighting with this issue
for 2 weeks, thinking that's my bogus printer configuration. The only thing
surprised me - why test page from cups or any page from mozilla firefox prints
OK and pages from any gnome program haven't been printed at all. See buggy ps
file attached.

Printing worked again only after I have put LC_NUMERIC="POSIX" in
/etc/environment file.

Please reopen and fix this bug again, since LC_NUMERIC="POSIX" is ugly and
incorrect with many locales.
Comment 10 2004-06-16 17:31:23 UTC
Created attachment 28775 [details]
Bogus PS file

This is an example of file created if LANG is set to lt_LT.UTF-8
Comment 11 Andreas J. Guelzow 2004-06-16 17:57:32 UTC
From the postscript file:

/FullName (Andale Mono Regular) readonly def
/FamilyName (Andale Mono) readonly def
/Weight (Book) readonly def
/ItalicAngle 0,000000 def
/isFixedPitch true def
/UnderlinePosition -100 def
/UnderlineThickness 50 def

The problem is the comma in the /ItalicAngle line.
Comment 12 Andreas J. Guelzow 2004-06-16 18:05:44 UTC
It arises from line 730 in gp-tt-t1.c where we have:
"/ItalicAngle %f def\n"
Comment 13 Jody Goldberg 2004-06-22 17:51:01 UTC
A simple fix seems reasonable here given that the code is gone in head.