Re: [Plplot-devel] Greek characters in qt-driver

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

On 2010-10-07 12:28+0100 Steve Schwartz wrote:

> Hi Alan,
>
> On Wed, 2010-10-06 at 18:14 +0100, Alan W. Irwin wrote:
>> Furthermore, I think your best workaround is not to fiddle with the
>> Hershey to unicode transformation yourself (since that implies you
>> would have to patch PLplot indefinitely), and instead let your users
>> know there have been some changes in the Hershey to unicode
>> transformation table, and they should look at example 7 results at
>> http://plplot.sourceforge.net/examples.php?demo=07 (which is the cairo
>> result) or run example 7 with -dev qtwidget for themselves for
>> guidance about which Hershey indices to use.
>
> This doesn't work for us. Our users don't programme plplot calls, nor do
> they (very often) specify a glyph by its Hershey/Unicode. Indeed, I hit
> the problem with the Greek characters by having #gh in a string used as
> an axis label - and we actually trap out the word "theta" in strings and
> convert it for our users to #gh.

Hi Steve:

<important aside> Because of what you said above, I checked the first
page of example 23 (the page that checks all the #g escapes) and found
(much to my chagrin) that unicode devices were giving different
answers for #g than the corresponding Hershey devices for epsilon,
theta, and phi.  To get one foot back on dry land I then compared #g
escape results for our svn trunk version with #g escape results for
PLplot-5.1.0 (!), and there are no differences (thank God) for Hershey
devices (which is all there were back then).  I then traced the reason
for this long-standing Hershey interpretation of #g escapes for
epsilon, theta, and phi to fonts/font11.c (see new documentation
inside pldeco for src/plsym.c). I then (revison 11252) made
corresponding changes to plP_text in src/plcore.c for the unicode case
so that unicode-aware devices would follow the Hershey-aware device
choice of #g interpretation.  This got rid of the example 23 first
page discrepancies between the two kinds of devices.  However, this
further change may screw up unicode device users like you who are
counting on the previous inconsistent (with Hershey) #g interpretation
for unicode-aware devices for any of epsilon, theta, and phi.  Therefore, I
have warned about this important change in our forthcoming release
notes, e.g., README.release in the svn trunk version of PLplot.
</important aside>

For unicode devices, #g escapes should be viewed as a legacy escape
mode to make results for those devices as close as possible to what we
have historically obtained (warts and all) with Hershey devices.  And
revision 11252 finally made this expected correspondence with Hershey
results for the #g escapes prevail.

For the QSAS case, the fact that you trap for words like "theta"
should simplify the issue for you. Instead of using a legacy #g escape
to represent trapped spelled-out Greek letters like "theta", I suggest
the safest thing for you to do (considering the PLplot interpretation
changes for #g in the unicode case) is to use the unicode glyph that
you want via a PLplot unicode escape (e.g., "#[0x03b8]" or
"#[0x03d1]") or a UTF-8 encoded string (e.g., "θ" or "ϑ").

You also imply above your users do have access to PLplot unicode
escapes and/or UTF-8 although not very many of them use that (yet)
presumably because you don't advertise that facility.  If you do
decide to bring up this subject with your users, I suggest you
recommend to them using the PLplot unicode escapes and/or UTF-8
encoded strings rather than the legacy PLplot Hershey code escapes or
#g escapes (assuming they are using a unicode-aware device driver like
qt).

To generate the above UTF-8 theta results for this post (which I hope
your mailer can read), I dragged and dropped from the gucharmap theta
glyphs to the guchamap "text to copy" bar, and then cut and pasted
from that bar.  That is obviously a pretty clumsy UTF-8 input method
for math symbols. but if users are willing to put up with that or have
access to a simpler UTF-8 input method, then I would always recommend using
UTF-8 strings over PLplot unicode escapes for string input
to 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); 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
__________________________