On Tue, 2010-01-19 at 11:23 -0200, Cesar Strauss wrote: > Peter Clifton wrote: > > I'm trying to nail the root cause of this now.. > > > > Could you try with this version of gschem (which should spew a load of > > "1,23 = 1,23" or something similar. (To the console - assuming you can > > retrieve that output). > > > > I get: > Debugging font issue, 1,230000 = 1,230000 > > By going to the Control Panel -> Regional Options, and choosing between > Portuguese and English, I can change the output at will. Can you > reproduce it on your Windows laptop?
I ought to be able to try that later, but I'm not sure if it has any other LOCALEs available. (And I don't have the Install disks). > I guess it would be useful to ask on the glib list how to override this, > since you seem to be able to do it on Linux just fine. Indeed.. When I install a locale which has "," as the decimal specifier (e.g. fr_CA.UTF-8), and run gschem with: LC_NUMERIC=fr_CA.UTF-8 ./gschem I still get "Arial 10.400000" as my font string (which is correct). However - it would appear that the override code isn't working on Win32 - which could have wider implications for file load / save (Although I can't recall where - if anywhere we read floating point from the file). Does it make any difference if you edit gschem.c, and change: setlocale(LC_NUMERIC, "POSIX"); to setlocale(LC_NUMERIC, "C"); (Or anything else?) NB: There are two calls to setlocale for LC_NUMERIC. Apparently this working correctly is required for correct postscript output. Can you see the Win32 build placing "," in any postscipt print output where it should be "."? It true that changing LC_NUMERIC is a poor work-around for the issue at hand anyway.. glib provides some functions which format doubles into a string using the "." separator, irrespective of LOCALE. I have the workaround for the font issue - and we probably need to find one for the postscript output. Going forward, I'd like to see us leave LC_NUMERIC alone, and use the specialised functions to emit and parse data which we know to use ".". Unfortunately, the g_ascii_dtostr() function has somewhat of a LAME API, in that it requires a fixed buffer: char buf[G_ASCII_DTOSTR_BUF_SIZE]; fprintf (out, "value=%s\n", g_ascii_dtostr (buf, sizeof (buf), value)); Oh well - not too awful. If we eventually fix things in this way, we'll need to be extra careful we don't inadvertently break anything: File loading / saving and printing being the major ones I can envisage. I've got plans for Cairo printing anyway, which takes care of that (if we drop the old printing code) - and the file format doesn't use a lot (if any?) non-integer fields. Best wishes, Peter C. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user