Hi AlanI was looking for a previous email you sent about testing Tcl and found 
this, which I realised that I can now shed some extra light on, although I have 
changed the subject as the topic has changed somewhat - I have just been 
looking at some Unicode things while building (and finding bugs in) other 
libraries related to Unicode builds. When searching about this things I found 
someone posting saying that it is impossible to reliably create string literals 
in VC++ with UTF8 encoding. Setting the source code file to UTF-8 does not 
guarantee this and apparently the compiler will change string literals to 
UTF-16. See 
http://stackoverflow.com/questions/688760/how-to-create-a-utf-8-string-literal-in-visual-c-2008
 for details. I have in the past passed Unicode string literals to plplot and 
it has worked. However I don't know if that is still the case as the post say 
this behaviour has changed with VC++ versions. I will check. If it doesn't then 
I don't know if there is anything that we can (or should) do about it. Phil
      From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
 To: Arjen Markus <arjen.mar...@deltares.nl> 
Cc: Phil Rosenberg <philip_rosenb...@yahoo.com>; PLplot development list 
<Plplot-devel@lists.sourceforge.net> 
 Sent: Tuesday, 23 September 2014, 16:39
 Subject: Re: [Plplot-devel] tcl build problem
   
On 2014-09-23 10:36-0000 Arjen Markus wrote:

> Hi Phil,

> I will definitely try these changes with Cygwin and MinGW. Pairs of
functions for handling ASCII and UNICODE strings are ubiquitous under
Windows and I do not expect trouble like Cygwin or MinGW not
supporting the two flavours. Still, that needs to be checked.

To Arjen and Phil:

To interject one additional consideration here, user input to PLplot
on both Unix and Windows should be in the UTF-8 encoding of unicode,
but the actual strings containing those UTF-8 bytes are assumed by our
code to be contained in ordinary char * strings and NOT wide
characters.  That's the whole point of UTF-8, it doesn't require wide
characters to contain it.  Instead, the number of UTF-8 characters
encoded as bytes in a normal string is sometimes less (if two or more
bytes are used in a character encoding) than the number of bytes in
the string, but that is not an issue for us since all our string
processing of user input simply requires a NULL byte at the end to
mark the end of the UTF-8 string.

Note, we actually do no internal text rendering using the raw user
UTF-8 input. Instead, in all cases we immediately translate that char
* user input from UTF-8 to PLUNICODE (32-byte integer) arrays, and use
those PLUNICODE arrays internally for the text rendering.

So I am virtually positive when there is a Windows macro choice
between normal (so-called ascii) and wide characters anywhere in our
code, than in most (or all?) cases, that choice should be replaced by
the definite narrow version similar to the change Phil just did for
the src/ltdl_win32.c case.



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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________


  
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to