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 __________________________ ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
