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)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: Biesinger, Assigned: roland.mainz)

Details

(Keywords: intl)

Attachments

(1 file, 2 obsolete files)

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.
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 ?
Swapping QA <--> Owner ...
Assignee: katakai → Roland.Mainz
QA Contact: Roland.Mainz → katakai
Severity: minor → critical
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
CC:'ing ftang@netscape.com ...
Summary: Printing doesn't work in de_AT@euro locale → Printing does not work in de_AT@euro locale
Attached patch Patch for 2002-03-15-08-trunk (obsolete) — Splinter Review
I'll take the setlocale()-way - PostScipt module does the same... :)
Keywords: intl, patch, review
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+
Attachment #74826 - Attachment is obsolete: true
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+
Filed bug 131867 ("Our use of setlocale() is not threadsafe") ...
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+
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.
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+
xx@@@!!!... ;-( I'll file a new patch...
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.
Attachment #74854 - Attachment is obsolete: true
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 ?
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 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+
patch checked in on trunk
Marking bug as FIXED. Biesi: Can you verify, please ?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
great, works now marking verified.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: