|
From: Zoltan B. <zb...@du...> - 2005-05-13 07:32:36
|
Hi Bob,
I don't know whether you received my mail, I send it again.
I definitely havent't got it back from rlib-devel.
So, Hungarian problems again.
Now I reached a phase where my program actually compiles and works
under Windows, and links to RLIB. But the resulting PDF is unusable.
Of course I saved it in an O_BINARY file. The problem is that printf(),
et.al. are conforming to the locale settings, so controlling numbers
in the PDFs are written as e.g.
/Frpdf0 9,000 Tf
instead of
/Frpdf0 9.000 Tf
since the decimal separator is a comma, not a dot here in Hungary.
A simple trick will do it (I fixed unixODBC this way in 2000):
-------------------------------------------
char *saved_locale;
saved_locale =3D strdup(setlocale(LC_ALL, NULL));
/* national decimal separator here */
setlocale(LC_ALL, "C");
/* decimal dots strictly required here */
setlocale(LC_ALL, saved_locale);
/* national decimal separator again */
free(saved_locale);
-------------------------------------------
Fortunately setlocale() exists under MingW, too.
I haven't made a patch against RPDF yet, but you know better
where to fix it.
On a sidenote, I don't know why it doesn't happen
under Linux with GTK-2.4, I have to investigate it.
Here's the only difference at program initialization:
...
#ifdef NEED_WINDOWS_H
locale =3D g_win32_getlocale();
#else
locale =3D g_strdup("UTF-8");
#endif
bind_textdomain_codeset (GETTEXT_PACKAGE, locale);
...
Maybe bind_textdomain_codeset() doesn't call setlocale()
but g_win32_getlocale() does.
AFAIK under GTK-1.2, either bindtextdomain() or gnome_init()
called setlocale(). Although I initialize GTK2 as
gtk_set_locale ();
gtk_init (&argc, &argv);
and my debugging printf() prints doubles with decimal comma,
RLIB produces correct PDFs under Linux. Strange.
Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi
|