Closed
Bug 131831
Opened 23 years ago
Closed 23 years ago
Printing does not work in de_AT@euro locale
Categories
(Core Graveyard :: Printing: Xprint, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: Biesinger, Assigned: roland.mainz)
Details
(Keywords: intl)
Attachments
(1 file, 2 obsolete files)
1.54 KB,
patch
|
Biesinger
:
review+
scc
:
superreview+
|
Details | Diff | Splinter Review |
XPrint printing seems to only work with locales using . as decimal seperator,
e.g. en_US or POSIX or C, but not de and derivatives.
Assignee | ||
Comment 1•23 years ago
|
||
Ohhh, fun.
I assume this is caused by
http://lxr.mozilla.org/seamonkey/source/gfx/src/xprint/xprintutil.c#669 ...
From the scanf(3S) manual page:
-- snip --
The scanf() function in all its forms allows for detection
of a language-dependent radix character in the input string.
The radix character is defined in the program's locale
(category LC_NUMERIC). In the POSIX locale, or in a locale
where the radix character is not defined, the radix charac-
ter defaults to a period (.).
-- snip --
Does anyone have a suggestion how to force sscanf() to use the C/POSIX locate
when parsing the data from Xprt ?
Assignee | ||
Comment 2•23 years ago
|
||
Swapping QA <--> Owner ...
Assignee: katakai → Roland.Mainz
QA Contact: Roland.Mainz → katakai
Assignee | ||
Updated•23 years ago
|
Severity: minor → critical
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Assignee | ||
Comment 3•23 years ago
|
||
CC:'ing ftang@netscape.com ...
Assignee | ||
Updated•23 years ago
|
Summary: Printing doesn't work in de_AT@euro locale → Printing does not work in de_AT@euro locale
Assignee | ||
Comment 4•23 years ago
|
||
I'll take the setlocale()-way - PostScipt module does the same... :)
Assignee | ||
Updated•23 years ago
|
Comment 5•23 years ago
|
||
Comment on attachment 74826 [details] [diff] [review]
Patch for 2002-03-15-08-trunk
- spacing around the sscanf() should be 2-space
- open another bug that our setlocale() code is not threadsafe. It *is* a
problem, and we shouldn't lose it, but the problem is really the sscanf() API
and we're doing this elsewhere anyway. No need to hold this up for that.
r=jkeiser with that
Attachment #74826 -
Flags: review+
Assignee | ||
Comment 6•23 years ago
|
||
Attachment #74826 -
Attachment is obsolete: true
Comment 7•23 years ago
|
||
Comment on attachment 74854 [details] [diff] [review]
New patch for 2002-03-15-08-trunk per jkeiser's comments
r=jkeiser
Attachment #74854 -
Flags: review+
Assignee | ||
Comment 8•23 years ago
|
||
Filed bug 131867 ("Our use of setlocale() is not threadsafe") ...
Comment 9•23 years ago
|
||
Comment on attachment 74854 [details] [diff] [review]
New patch for 2002-03-15-08-trunk per jkeiser's comments
looks fine to me- sr=attinasi
Attachment #74854 -
Flags: superreview+
Comment on attachment 74854 [details] [diff] [review]
New patch for 2002-03-15-08-trunk per jkeiser's comments
In my professional opinion *scanf is a pit of evil, but a=roc+moz
Attachment #74854 -
Flags: approval+
Reporter | ||
Comment 11•23 years ago
|
||
Roland, are you sure that this line returns the old locale and not the one just set?
+ cur_locale = setlocale(LC_NUMERIC, "C");
From the manpage:
RETURN VALUE
A successful call to setlocale() returns an opaque string
that corresponds to the locale set.
Reporter | ||
Comment 12•23 years ago
|
||
Comment on attachment 74854 [details] [diff] [review]
New patch for 2002-03-15-08-trunk per jkeiser's comments
marking as needs work.
I tested, and setlocale(LC_NUMERIC, "C"); returns "C".
You should change it to:
cur_locale = setlocale(LC_NUMERIC, NULL);
setlocale(LC_NUMERIC, "C");
Attachment #74854 -
Flags: needs-work+
Assignee | ||
Comment 13•23 years ago
|
||
xx@@@!!!... ;-(
I'll file a new patch...
Reporter | ||
Comment 14•23 years ago
|
||
I just had a look at NSPR. It does not use locale information, so using it would
avoid the setlocale calls; this is probably a better solution than in this patch.
Assignee | ||
Comment 15•23 years ago
|
||
Attachment #74854 -
Attachment is obsolete: true
Assignee | ||
Comment 16•23 years ago
|
||
Christian Biesinger wrote:
> I just had a look at NSPR. It does not use locale information, so using it
> would avoid the setlocale calls; this is probably a better solution than in
> this patch
The problem is that the XprintUtil code is used outside the Mozilla tree, too -
where NSPR is not available.
One item on my ToDo list is to rewrite the parser in the near future (and I
added the item "avoid sscanf()" to that list... :) - the current one has become
a hacked hack with hacked fixes (but it works... :)
But I need a fix for the 1.0 release - which means I need a quick solution for
this issue...
----
biesi, can you r= , please ?
Reporter | ||
Comment 17•23 years ago
|
||
Comment on attachment 74960 [details] [diff] [review]
New patch for 2002-03-17-08-trunk per biesi's comment
r=biesi
Attachment #74960 -
Flags: review+
Comment 18•23 years ago
|
||
Comment on attachment 74960 [details] [diff] [review]
New patch for 2002-03-17-08-trunk per biesi's comment
sr=scc, of course, with all the cautions issued above
Attachment #74960 -
Flags: superreview+
Comment 19•23 years ago
|
||
patch checked in on trunk
Assignee | ||
Comment 20•23 years ago
|
||
Marking bug as FIXED.
Biesi:
Can you verify, please ?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•