Re: [Plplot-general] cmake bulid for .sln error

[Alan W. I. <ir...@be...>]

On 2013-10-20 10:17-0000 hubin wrote:

> Thank you;thank-you;I see the math graph;oh my god,I do see it !I use NMake, The IDE is too hard for me,Nmake  work fine,now i want to share my experience with you ;i got some error with nmake ,and I try solve some,I'm a Chinese college student, When i use Nmake just like you show in wiki;i got error with"..... examples\c\x18c.c  line 82(I use notepad++ open it ),the fourth parameter "." is error,I think because I come from china ,so the character"." show error in my PC when i open it with notepad++,the character"." turn into "口",I edit it to ".", so it's build fine,work fine;
> the second error is x24c.c,it's a word "peace" use different language; in my PC,I can't see some language "peace ";they just show"口" ;because i  use windows;so i change the code char * peace[]->wchar_t *peace[];and i use API WideCharToMultiByte change UNICODE to Utf-8,So it build fine ,but work error, It can't show non-English character;
> the third error is "x33c.c",you define some "special_symbols",It's wrong when nmake build ;
> I got a warning and a error with each of the three ".c" files in nmake ,the warning is c4819 and the error is c2001I find if I open ".c" files and save them with "Unicode",Then all three files build fine.but just get a warning c4566;Then i find ".cc" files is same as the ".c",Now ,How do you think about it?and I want to know why don't use Unicode to replace of ASCII,Unicode have big bugs?

Hi Fly:

I am glad to hear you have been making good progress with Arjen's
help.  But I thought I would jump in here with an answer
to your unicode questions.

PLplot's design is that _all_ strings in our API are interpreted as
the UTF-8 encoding of unicode when we translate those results into our
internal representation of unicode.  We chose the UTF-8 encoding over
all the other encoding alternatives for the strings in our API because
UTF-8 has a huge advantage over the others; ordinary ascii characters
are a subset.  So such strings can contain just single-byte ascii
characters or a mixture of those and multi-byte UTF-8 characters to
give complete access to all of unicode.

So adjust your unicode encoding to UTF-8 for all strings you use for
PLplot, and all our code should just build without issues.  Also, you
should note that most of our standard examples just use the ascii
subset of UTF-8.  And example 23 demonstrates you can work exclusively
in ascii if you are willing to input a lot of numerical escape codes.
But ultimately that is a rather clumsy approach to get access to
unicode so some of our examples (18, 24, 26, and 33) are written to
take advantage of the multi-byte subset of UTF-8. I notice it is those
examples where you are having trouble.  For them, you should not
change anything other than to convince Windows that the encoding is
UTF-8, and then all builds of all our libraries, devices, and examples
should proceed smoothly with no changes in the code required.

Once, everything has been built properly, then the further question is
which of our device drivers can properly use our unicode technology.
The answer is only our modern unicode-aware device drivers (svg,
psttf, cairo, qt, and wxwidgets) can render the results correctly for
examples 18, 23, 24, 26, and 33 with appropriate system font glyphs.
(The wxwidgets device has some unicode limitations we are currently
trying to overcome, but the rest are fine.)

Note that all the unicode-aware devices other than svg
requre certain external libraries be installed. (The psttf device driver
requires the libLASi, Pango, and Cairo external libraries; the cairo
device driver requires the Pango and Cairo external libraries; the qt
device driver requires the Qt4 external libraries, and the wxwidgets
device requires the external wxwidgets library.)  Those libraries
are readily available on Linux and Mac OS X, but can be an issue
on Windows.

One excellent option to get access to a lot of this unicode PLplot
functionality on Windows is to use Cygwin since that distribution of
software does contain the Pango, Cairo, and Qt4 external libraries
required by our cairo and qt device drivers, which are our two best
unicode-aware device drivers with many different devices to use. 
Arjen has recently tested that platform in detail, and largely gotten
good results with it.  See his recent comments in our Wiki.

However, if you prefer not to install Cygwin on Windows, and still
want access to the unicode part of PLplot (i.e., be able to use the
functionality that is presented for examples 18, 23, 24, 26, and 33)
then one good choice is the svg device which does not depend on any
external library. However, for that case you will need good svg
viewing software (e.g., the firefox browser) to view the svg results.

Another possibility is to build libLASi, Pango, Cairo, Qt4, and/or the
external wxwidgets library yourself.  Normally, that is difficult, but
I am working on a project (see cmake/build_projects) whose long-term
goal is to make such builds convenient on all platforms.  The
build_projects project is not ready at the moment but watch this space
for future announcements concerning it.

A final Windows possibility, of course, is simply to stick with the
ascii subset of UTF-8 and ignore the additional PLplot string
capabilities that are demonstrated by examples 18, 23, 24, 26, and 33.
But in my opinion that is a defeatist attitude, and I would advise
instead to (1) look carefully at the svg device results for those
examples with the firefox browser or some other good svg viewer to see
what you are missing, (2) install Cygwin to take advantage of the many
unicode-aware cairo and qt devices, or (3) in the long-term wait for a
convenient building solution from build_projects for all the external
libraries that are required by our unicode-aware devices.

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
__________________________