Re: gEDA-user: Test gschem bug...

[Peter Clifton <pcjc2@xxxxxxxxx>]

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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user