* Alan W. Irwin <irwin@...> [2005-01-06 11:47]:
> Can someone tell me how to make the Greek array defined by
>
> char greek[] = "ABGDEZYHIKLMNCOPRSTUFXQWabgdezyhiklmncoprstufxqw";
>
> accessible to both plcore.c and plsym.c without duplicating as now? I
> assume it should go in a header, but which header? Since this array is
> normally not accessed by the user should it go in plplotP.h? Also, please
> give me all other syntax details such as whether it should be static or not
> (or better yet, make the commit yourself).
You should never make a variable *_definition_* in a header file, otherwise
the variable will end up defined in every .o object whose .c source includes
the header. You should only make variable *_declarations_* in a .h header
file. In your case, just put:
extern char greek[];
in plplotP.h and keep the global definition (as you wrote above) in
plcore.c. Of course, you should remove the definition in plsym.c.
At any rate, since you are making this variable global, give it a more
informative (and probably longer) name than just "greek" in order to avoid
name space collisions.
--
Rafael

On 2005-01-06 01:49-0800 Alan W. Irwin wrote:
> There are currently two exceptions. The plsym code for Hershey fonts
> produces a blank for letters not in the Greek array. My correction to the
> unicode case for plcore.c currently just produces the letter itself. Thus
> because j and v are not in the Greek array, you will see j and v plotted (in
> the 7th and 8th lines) instead of a blank.
Fixed now and as a result a nice unicode space appears for the
testunicode.png plot for any invalid Greek escape sequence such as all
upper/lower case combinations of #gj and #gv.
Can someone tell me how to make the Greek array defined by
char greek[] = "ABGDEZYHIKLMNCOPRSTUFXQWabgdezyhiklmncoprstufxqw";
accessible to both plcore.c and plsym.c without duplicating as now? I
assume it should go in a header, but which header? Since this array is
normally not accessed by the user should it go in plplotP.h? Also, please
give me all other syntax details such as whether it should be static or not
(or better yet, make the commit yourself).
Alan
__________________________
Alan W. Irwin
email: irwin@...
phone: 250-727-2902
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 Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________

I attach the following files:
1. test.py (1.3 KB) "test.py",
2. lettertest.py (981 B) "lettertest.py",
3. testhershey.png (6.8 KB) "testhershey.png",
4. testbad.png (36 KB) "testbad.png",
5. testunicode.png (36 KB) "testunicode.png"
lettertest.py may eventually become the prototype of yet another example to
show off Greek letters done via the #g (or #G) escape sequences. It is just
a start, of course, and we will probably want to add a lot of examples of
the #[nnnn] sequences in the part of the unicode table devoted to
mathematical symbols (especially those unicode math symbols that have no
Hershey equivalent).
For the new version of plcore.c that I just committed, you make install and
then do the following:
* change directories to the _installed_ examples/python
* copy the two python files into that directory
* Then create two of the three png results:
./test.py -dev png -o testhershey.png
./test.py -dev png -o testunicode.png -drvopt text,smooth,24bit
(You can also create testbad.png by running that last version with plcore.c
unmodified by my fix.)
Note, if people like the results of my correction, then I don't claim to be
that hot a C programmer, and somebody with more C skills should go into the
Greek section of plcore.c and check and refine what I did.
The problem occurs for Greek escape sequences in text strings and is
therefore not tested by the example 7 code so that is why I had to come up
with a new test example. testbad.png shows the result generated by the old
plcore.c code. As you can see (also from testletter.py), the lines
alternate between latin symbols and their Greek equivalents. If you compare
line 7 and line 8 at first the results look pretty good. But you soon
realize from careful comparison that there are misalignments because there
are only 24 and not 26 Greek characters. There is no Greek equivalent of j
or v, and the result is j maps to kappa, k maps to lambda, and it gets even
worse at v and beyond so that eventually you get y and z mapping to a and b.
I fixed the problem exactly like plsym.c fixes it by using the Greek array
and the plP_strpos function to find the index corresponding to the input
letter. The result is shown in testunicode.png which is almost identical
(in letter shapes) with the testhershey.png result, i.e., my correction
gives good forward compatibility in that old scripts with non-Hershey
unicode fonts will produce the expected Greek letter results with the Greek
escapes.
There are currently two exceptions. The plsym code for Hershey fonts
produces a blank for letters not in the Greek array. My correction to the
unicode case for plcore.c currently just produces the letter itself. Thus
because j and v are not in the Greek array, you will see j and v plotted (in
the 7th and 8th lines) instead of a blank. That should be corrected (along
with the duplicated code for the #g and #G cases, two definitions of the
Greek array in two different files, and other code crudities). But I
thought I had better go ahead with a preliminary rough but working fix to at
least stir up some discussion of this problem.
Andrew, I know from off-list discussions with you a few weeks ago you felt
you didn't want to support forwards compatibility for this case, but I now
think we have to do something because of the misalignments between latin and
greek alphabets caused by the different numbers of letters.
It seemed to me the PLplot Hershey font method in plsym.c that deals with
these misalignments gives pretty good results with an easy mnemonic way for
users to remember the order (see also our documentation of this order at
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.3.1/escape-sequences.html)
so I decided to give it a go with the nice-looking results that you see
in testunicode.png.
Let me know what you think.
Alan
__________________________
Alan W. Irwin
email: irwin@...
phone: 250-727-2902
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 Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________