I have assigned a new subject because this topic deserves its own thread. On 2009-09-01 11:24-0700 Alan W. Irwin wrote:
> [...] Thus, I think our best solution to this whole issue is to save > the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then > restore the user locale in both cmap0_palette_read and plspal1. This method > absolutely guards against any locale issue (say for a different library than > qt) ever again screwing up palette file reading so this is what I like. > > What do you think of this idea? I have continued to think some more about LC_NUMERIC issues in PLplot, and to give some context to further discussion of this, have a look at http://en.wikipedia.org/wiki/File:DecimalSeparator.png. My own country of Canada has different decimal separators depending upon whether you are located in Quebec or otherwise, and a substantial fraction of the countries in the world use the comma for the separator rather than a period. The current status is our plots all correspond to setlocale(LC_NUMERIC, "C"); That is they use the period as the decimal separator on axis labels. This is probably consistent with the policy of many scientific publishers out there, but there are almost guaranteed to be some publishers that accept a decimal separator in plots that is whatever the author likes and even some that demand the comma separator regardless of the locale of the author. In addition, although we advertise PLplot as a scientific plotting library, it is also used in other contexts as well where there may be a need to follow the local locale with a comma decimal separator. Thus, for maximum PLplot usefulness, I think we should have a global variables local_locale set to 0 or 1 at user option so that plinit calls either setlocale(LC_NUMERIC, "C"); for local_locale = 0 or setlocale(LC_NUMERIC, ""); for local_locale = 1, where the first one should be the default, and the latter one gives complete flexibility since it obtains LC_NUMERIC from the environment (which can be set to anything by the user). Furthermore, this would fit in with my proposed solution to the above issue if we always setlocale(LC_NUMERIC, "C"); before reading palette files regardless of local_locale and restore to either of the above two choices depending on local_locale. Finally, in qt.cpp we should change back to the PLplot locale specified by local_locale just in case the Qt4 libraries change it. I hope to implement all of this later today or early tomorrow so please let me know quickly your comments on my proposal to deal with LC_NUMERIC issues in PLplot. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
