Hi Alan, On 2009-09-09 21:23, Alan W. Irwin wrote: > On 2009-09-09 13:59+0200 Arjen Markus wrote: > >> Hi Alan, >> >> I have been experimenting a bit with the test program I sent earlier >> to see how this works on Windows. > >> #include "stdafx.h" >> #include "locale.h" > >> pstr = setlocale(LC_NUMERIC, ""); > > Hi Arjen: > > Your continued testing on Windows has been most helpful. > > Those are exactly the setlocale function arguments used by the general (not > just an example 1 option any more as of revision 10388) -locale > command-line > option for PLplot. I am very pleased to hear that the setlocale function > exists on Windows and has the same arguments. Is the #include "stdafx.h" > actually necessary? Please try a windows build of PLplot to see whether it > is necessary. If so, the place to put #include <stdafx.h> it is right > before the
Sorry for the confusion: the line '#include "stdafx.h"' is a consequence of Visual Studio creating a default source file for you, if you are not careful. (I find it a nuisance, but then I never use the associated functionality.) > > #include <locale.h> > > in plplotP.h surrounded by preprocessor logic so #include <stdafx.h> does > not happen for non-windows platforms. > > I am also pleased to hear that those setlocale arguments have an effect on > Windows (at least for output). That means you should be able to see comma > separators for all axis labels and contour interval labels when you run > example 9 (just like I do when I use the nl_NL.utf8 locale). Can you > confirm > that? I will try that. I may be able to do that tonight. > >> ... I remembered suddenly that on Windows you can set the regional >> settings. That contained a period ... So setting that to a comma, >> I get: >> >> chklocale 1,3 Dutch_Netherlands.1252 >> Number: 1,200000 -- Dutch_Netherlands.1252 >> Read: 1,000000 >> Read: 1,000000 -- (null) >> >> Note: the comma is apparently not recognised on input, it is used >> on output! > >> From my perspective, the principal locale issues are (1) allowing PLplot > users to control the LC_NUMERIC locale used for PLplot via the -locale > command-line option rather than just leaving it up to external applications > and libraries and (2) protecting critical areas of PLplot against any > locale > chosen via the -setlocale mechanism or external libraries. It looks like > both of these issues have now been dealt with for Linux and (from your > simple tests) Windows as well, although more testing is obviously required > on both platforms (and also OS X). > I agree, the current implementation confines the effects of PLplot's -locale to PLplot routines and that is what you really need. Locale settings are messy enough as they are. > To my mind, the additional issue of recognizing the comma separator for our > floating-point options for the command line is not as important as the > other > two issues. The complete (as far as I can tell) list of such options is > -mar, -a, -jx, -jy, -ori, -bg, -wplt,-fsiz, and -dpi. All of those use > atof > to determine the floating-point values of the options. It does make sense > from the consistency point of view to support comma separators for these > options if you are specifying for plots generated by PLplot, but the result > is dependent on how scanf/atof is implemented for each different platform > version. For Linux, my sense (from all the Linux locale reading I have > been > doing the last few days, although I cannot now find a specific > reference) is > support of the LC_NUMERIC locale for scanf/atof has been fairly recent. > You > may have a similar situation for Windows with earlier platforms not > supporting LC_NUMERIC locale for scanf/atof and later ones supporting it. > Hm, I used both MSVC 6.0 and MSVC 2008 (more or less the latest release). MicroSoft have always been keen on localisation, so I am a bit surprised that such basic functions as scanf() do not adhere to the settings. The asymmetry actually causes problems, as you can not write a file with comma separators and read it back again. But that is a different discussion. > Anyhow, could you add your experience to the locale notes in README.release > (especially about the regional setting you had to change to get LC_NUMERIC > recognized on output for your particular Windows platform)? Once such > experience has been collected for all platforms, then I will put the result > in our wiki and also in our DocBook form of documentation. > Sure. Regards, Arjen ------------------------------------------------------------------------------ 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
