Bug 109568 - gedit giving warnings under a Persian locale
Summary: gedit giving warnings under a Persian locale
Alias: None
Product: Fedora
Classification: Fedora
Component: gedit   
(Show other bugs)
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
Keywords: i18n, MoveUpstream
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-09 18:41 UTC by Roozbeh Pournader
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-11 13:59:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to fix two-byte decimal separator problem (354 bytes, patch)
2003-11-10 13:45 UTC, Behdad Esfahbod
no flags Details | Diff
replacement patch (433 bytes, patch)
2003-11-10 14:43 UTC, Behdad Esfahbod
no flags Details | Diff
glib-2.2.3 strtod 2byte decimal separator patch (415 bytes, patch)
2003-11-10 14:49 UTC, Behdad Esfahbod
no flags Details | Diff

Description Roozbeh Pournader 2003-11-09 18:41:31 UTC
Description of problem:
gedit gives warnings when running under the "fa_IR.UTF-8" locale. It
seems that it can't parse floating point numbers. This is most
probably a fontconfig, gtk2 or glib2 bug, but I can't say exactly
which one.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run "LANG=fa_IR.UTF-8 gedit" from a gnome-terminal.

Actual Results:  The following warnings appear on the terminal before
gedit comes up:

/usr/share/themes/Bluecurve/gtk-2.0/gtkrc:50: error: scanner: digit is
beyond radix
Fontconfig error: line 172: "7.5": not a valid double
Fontconfig warning: line 173: missing test expression
Fontconfig error: line 184: "7.5": not a valid double
Fontconfig warning: line 185: missing test expression
Fontconfig error: line 196: "7.5": not a valid double
Fontconfig warning: line 197: missing test expression
Fontconfig error: line 436: "0.2": not a valid double
Fontconfig error: line 438: wrong number of matrix elements
Fontconfig error: Cannot load default config file

Expected Results:  No warnings should appear.

Additional info:

This is most probably due to the Persian locale using a decimal
separator that becomes two bytes when encoded in UTF-8.

I appreciate any help or pointer on how to find the source of the
problem, so I can patch it as soon as possible.

Comment 1 Behdad Esfahbod 2003-11-10 00:23:02 UTC
You went really good to the point.  Can't image how you didn't got it.
 Well, it's the first appearance of a very wide and important problem
with Persian locale:  decimal separator is the same for both Latin and
Persian set of digits, and is NOT the usual dot (".").  So you should
have got it already:  When setting the whole locale to fa_IR, scanf
simply does not parse floats with dot as separator!!!  Here is the
simple test:

#include <stdio.h>
#include <locale.h>
    double g = 0;
    setlocale(LC_ALL, "fa_IR.UTF-8");
    scanf("%d", &g);
    printf("%d\n", g);

Compile and run and see how 12.3 would be parsed as 12.

Fix:  In the mean time:  fontconfig parse it's config file with C
locale.  In the long run:  Add another decimal separator to the
locales definition.  You already know the issue.


Comment 2 Behdad Esfahbod 2003-11-10 06:27:27 UTC
Oops, Of course I mant "%lg" not "%d" in both cases above.
Here is it fixed:

#include <stdio.h>
#include <locale.h>
    setlocale(LC_ALL, "fa_IR");
    while (1) {
        double g = 0;
        char buf[100];
        scanf("%lg%[^\n]", &g, buf);
        printf("You entered %lg\n", g);

And here is the run:

You entered 123
You entered 123
You entered 123Ù«456

See how the Persian decimal separator works.

Comment 3 Roozbeh Pournader 2003-11-10 12:34:08 UTC
Behdad, it's not that problem. Try the same with a "fr_FR.UTF-8"
locale and see that the output of your program is the same (use the
comma instead of the Persian decimal separator in your last example).
While running gedit with with a fr_FR locale doesn't give you any

BTW, fontconfig can't switch locales while running. It's not thread
safe to do that, I've heard from Keith Packard.

So, no, I don't know the issue here. My real guess is two bugs, one in
glib and one in fontconfig.

Comment 4 Behdad Esfahbod 2003-11-10 13:45:34 UTC
Created attachment 95867 [details]
patch to fix two-byte decimal separator problem

Comment 5 Behdad Esfahbod 2003-11-10 13:46:31 UTC
Attaching the one line patch.  Here is the description of the problem:
 In fcxml.c, FcStrtod, when the decimal separator is two bytes, *end
gets computed wrong, so later FcParseDouble nags.

Keith:  Would you take care of upstream? ;-)

Comment 6 Behdad Esfahbod 2003-11-10 13:47:15 UTC
Oops, s/Keith/Roozbeh/

Comment 7 Behdad Esfahbod 2003-11-10 14:43:14 UTC
Created attachment 95871 [details]
replacement patch

fixed a bug in the patch ;)

Comment 8 Behdad Esfahbod 2003-11-10 14:49:11 UTC
Created attachment 95872 [details]
glib-2.2.3 strtod 2byte decimal separator patch

Here is the patch for exactly the same bug in glib2.

Comment 9 Roozbeh Pournader 2003-11-10 16:26:34 UTC
Tested both patches. They fix the problem. Trying to report them upstream.

Comment 10 Roozbeh Pournader 2003-11-10 16:44:12 UTC
Behdad, I just talked to keithp. keithp says there is no need for the
second patch. "buf_end will be > dot whenever dlen is > 1". Can you

Comment 11 Roozbeh Pournader 2003-11-10 18:16:12 UTC
fontconfig's bug fixed in its CVS HEAD and 2.2 branch. glib2's bug
reported at <http://bugzilla.gnome.org/show_bug.cgi?id=126640>.

Comment 12 Behdad Esfahbod 2003-11-11 02:27:19 UTC
Roozbeh:  Just for the record, we talked on IRC and you comment #10 is
not true.  Did you applied the second patch to fontconfig?

Please Close the bug as upstream.

Comment 13 Roozbeh Pournader 2003-11-11 13:59:36 UTC
Behdad: Yes, Keithp agreed that you were correct. The second patch was
applied to fontconfig.

Closing the bug as upstream.

Note You need to log in before you can comment on or make changes to this bug.