Re: [Plplot-devel] Greek characters in qt-driver
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: 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. 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
Re: [Plplot-devel] Greek characters in qt-driver
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. In short, we supply, as binary executable and/or packaged source, a high-level, interactive, GUI-driven application that is used by scientists who don't need to know what plplot is, who don't need to programme in C/C++, and in many cases who don't have the appropriate administrative authority or support on their platform to install/upgrade things. If we forced them in install separately the range of 3rd party software on which our QSAS depends (plplot - and by inference cmake, cdf from NASA, qt development kits, mingw - for windows, lapack, blas, and probably a few others) our user community would shrink to zero. So we supply a source tree in which all these elements are bundled. Our configure/make system builds all these elements (well, not qt). In particular, we unpack plplot and build it ourselves without using cmake. Our users, like those of Microsoft Word, expect the software to run out of the box, and to open saved sessions that had a greek theta in a plot and to still show a greek theta in the plot. Unlike Microsoft, when something doesn't work, we fix it. Moving to plplot brought us many advantages, both in terms of freeing ourselves from the fortran interface required by pgplot and more capabilities, which we have enhanced with two main contributions (the qt driver and qsastime) that we are happy to see adopted and maintained by your team. That saves us maintenance, but it is likely that, given our user community and the nature of our application, we will continue to need to tinker a bit. In part, of course, we don't follow every update of plplot, but just the ones that make a material difference or to ensure we don't get too far behind. Regards, Steve -- +---+ Professor Steven J SchwartzPhone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett LaboratoryE-mail: s.schwa...@imperial.ac.uk Imperial College LondonOffice: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +---+ -- 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
Re: [Plplot-devel] Greek characters in qt-driver
On 2010-10-05 15:18-0700 Alan W. Irwin wrote: > Note also these Greek-letter variations are all available in the same > font. So it is not a matter of suddenly changing fonts in the middle > of a string. Instead, it is using the same font with different Hershey > and therefore UCS4 indices representing different variant forms of > Greek letters depending upon what the user wants to do. Hi Steve: Having slept on this, the lesson I take away from this is I should always mention any changes in the Hershey to unicode transformation table and the implications of that in the release notes. But hopefully I have nailed it now and there will be no more such changes. 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. I have also thought a bit more about the planned plglyph argument list, and I have decided the last argument should be a text string like that used in plptex rather than a UCS4 index. IOW, plglyph would be a simple wrapper for repeat calls to plptex for each element of the x and y arrays. The advantage of this approach is it gives the user great flexibility in specifying the glyph and font following all the many different methods in http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.7/characters.html. It also allows the user to specify more than one glyph in the string to be plotted at each of the x, y points if they wanted that, but that would be an extremely unusual use case. Because of this proposed change in the argument list, the planned plglyph should make accessible all the glyphs available from plpoin (except for the special code=-1 point "glyph" which I doubt is used very much because it might be problematic for some devices and because our DocBook documentation does not mention this capability), all the glyphs available from plsym, and all the huge number of glyphs (a million of them?) that gucharmap shows are available on your system. 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
Re: [Plplot-devel] Greek characters in qt-driver
On 2010-10-05 20:29+0100 Schwartz, Steven J wrote: > Should plplot draw it's Greek theta from a script-like font when all the other Greek symbols (bar uppercase upsilon) are drawn from the default sans serif font? Would it look strange to a Greek person to see a word spelled with this mixture of fonts? > I suspect I'm the only one who might have noticed :-) Actually, I notice these things as well, but that was a deliberate change. If you look at the 600 section or 2100 section of example 7 with -dev xwin (i.e, Hershey fonts), you will see that there are two versions of episilon, theta, and phi available for the Hershey fonts. I changed the Hershey to unicode transformation to match those two variations of the three glyphs as closely as possible, and I have just confirmed that sections 600 and 2100 of example 7 give Greek letter variants for the qt and cairo devices that are in at least the same spirit of the Greek letter variants you see for -dev xwin. In other words, the point of plsym (and plpoin) for unicode-aware devices is to match what is done for the Hershey devices (whether right or wrong) as closely as possible for the best backwards compatibility. That is, if people went out of their way to use what they considered to be the best variation of Greek letters with Hershey devices, they could rely on that behaviour continuing with unicode-aware devices. Note also these Greek-letter variations are all available in the same font. So it is not a matter of suddenly changing fonts in the middle of a string. Instead, it is using the same font with different Hershey and therefore UCS4 indices representing different variant forms of Greek letters depending upon what the user wants to do. All this will be much clearer with the planned plglyph functionality. There, you will get whatever unicode glyph corresponds to the UCS4 index you specify. So typically you would window-shop in gucharmap until you find a glyph you like taking into account all variants mentioned in the character details. Then you use the UCS4 index of that glyph directly in the call to plglyph for your plot. Of course, the user of plglyph will still be subject to possible mistakes in how a given font designer renders the glyph. Also, the qt and cairo devices use generic fonts where an external library (e.g., fontconfig for cairo) decides on the best sans or serif choice to represent the glyph. That potentially means you could get several different fonts used in the same text string if a higher-ranked font had a lot of glyphs missing so you had to fall back to a lower-ranked fonts for some of the glyphs. But in practice that happens rarely since most OS's only deploy True-Type font choices with relatively large glyph coverage. To end on a philosphical note, I used to ignore fonts altogether back in the dark ages when there was no choice other than Hershey for PLplot. But I have become completely enthused about fonts now that PLplot gives access to such a wide variety of them that represent ~500 years of artistic and mathematical tradition. Totally cool! 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
Re: [Plplot-devel] Greek characters in qt-driver
Hi Alan Ok as I suspected it is a qt issue and I agree that the qt3 Oct 2010, at 21:01, "dabergs...@comcast. guys mostly make positive improvements - although the migration of our code from Qt3 to Qt4 was far from painless. Since we bundle plplot with our software and deal with a variety of users who won't want to fetch/install alternate qt installations we'll run with my workaroumd for the time being. Thanks for the confirmation that it should work on newer installations - I may check my own qt installation to see if I can configure it to pick up the necessary fonts. It leaves me with a more philosophical and aesthetic question that I pose without malice: Should plplot draw it's Greek theta from a script-like font when all the other Greek symbols (bar uppercase upsilon) are drawn from the default sans serif font? Would it look strange to a Greek person to see a word spelled with this mixture of fonts? I suspect I'm the only one who might have noticed :-) Regards Steve --- Steve Schwartz Space and Atmospheric Physics Imperial College London Tel 020 7594 7660 On 5 Oct 2010, at 19:00, "Alan W. Irwin" wrote: > On 2010-10-05 13:02+0100 Steve Schwartz wrote: > >> [...]Gucharmap shows both >> the symbols and alternatives, and the xcairo driver finds them, so I >> guess they reside somehow on my system but not accessed by my version of >> qt (4.5.3). > > I used to encounter this same difficulty (Qt was not as good at > finding system fonts as xcairo and gucharmap). I speculate that older > versions of Qt used their own library for finding system fonts and not > the standard fontconfig library that is used by xcairo and gucharmap > or else Qt used fontconfig in a poorly configured way. However, for > Qt-4.6.3 (the version that comes with Debian testing) I have not > encountered this issue. For example, the Hershey numbers below are > all rendered fine with example 7 and -dev qtwidget. > >> Hershey numbersplplot5.9.7 unicode change to this >> 46, 546 0x03d2 0x03a5 Upsilon >> 534 0x03d1 0x03b8 theta >> 98, 684, 21840x03f5 0x03b5 epsilon >> 686, 21860x03d5 0x03c6 phi variant > > As you can see from Section 2.28 of our release announcement, later > versions of Qt seem to solve a number of issues we see for earlier > versions of Qt so the fix for this font-finding issue appears to be > just one more fix in the series of Qt improvements that also doesn't > seem to have introduced any regressions (at least up to 4.6.3). So > TrollTech/Nokia seem to have a pretty good track record for > constantly improving Qt4. > > The Qt download site at http://qt.nokia.com/downloads/ gives you > access to the latest Qt version (currently 4.7.0) in binary form. If > that version works well for you (i.e., solves the above issue without > introducing any regressions), then you might want to recommend it to > your QSAS users that don't have access to Qt-4.6.3 or above from their > distribution. Alternatively, you could temporarily deploy the above > workaround until essentially all distros have updated to 4.6.3 or > above. > > Finally, these issues remind me again that plpoin and plsym access > unicode glyphs in an indirect and extremely limited way. Therefore, I > have decided it is long past time we introduced a new function > plglyph(n, x, y, ucs4) which allowed plotting glyphs corresponding to > the ucs4 index for those drivers which are unicode aware. Such a > function would allow users full and direct access to the extremely > wide variety of generic sans and serif glyphs that are available on > their system for unicode-aware device drivers like qt (with Qt-4.6.3 > or later) or cairo. I will try implementing a first cut at plglyph > later today. > > 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/list
Re: [Plplot-devel] Greek characters in qt-driver
On 2010-10-05 13:02+0100 Steve Schwartz wrote: > [...]Gucharmap shows both > the symbols and alternatives, and the xcairo driver finds them, so I > guess they reside somehow on my system but not accessed by my version of > qt (4.5.3). I used to encounter this same difficulty (Qt was not as good at finding system fonts as xcairo and gucharmap). I speculate that older versions of Qt used their own library for finding system fonts and not the standard fontconfig library that is used by xcairo and gucharmap or else Qt used fontconfig in a poorly configured way. However, for Qt-4.6.3 (the version that comes with Debian testing) I have not encountered this issue. For example, the Hershey numbers below are all rendered fine with example 7 and -dev qtwidget. > Hershey numbersplplot5.9.7 unicode change to this > 46, 546 0x03d2 0x03a5 Upsilon > 534 0x03d1 0x03b8 theta > 98, 684, 21840x03f5 0x03b5 epsilon > 686, 21860x03d5 0x03c6 phi variant As you can see from Section 2.28 of our release announcement, later versions of Qt seem to solve a number of issues we see for earlier versions of Qt so the fix for this font-finding issue appears to be just one more fix in the series of Qt improvements that also doesn't seem to have introduced any regressions (at least up to 4.6.3). So TrollTech/Nokia seem to have a pretty good track record for constantly improving Qt4. The Qt download site at http://qt.nokia.com/downloads/ gives you access to the latest Qt version (currently 4.7.0) in binary form. If that version works well for you (i.e., solves the above issue without introducing any regressions), then you might want to recommend it to your QSAS users that don't have access to Qt-4.6.3 or above from their distribution. Alternatively, you could temporarily deploy the above workaround until essentially all distros have updated to 4.6.3 or above. Finally, these issues remind me again that plpoin and plsym access unicode glyphs in an indirect and extremely limited way. Therefore, I have decided it is long past time we introduced a new function plglyph(n, x, y, ucs4) which allowed plotting glyphs corresponding to the ucs4 index for those drivers which are unicode aware. Such a function would allow users full and direct access to the extremely wide variety of generic sans and serif glyphs that are available on their system for unicode-aware device drivers like qt (with Qt-4.6.3 or later) or cairo. I will try implementing a first cut at plglyph later today. 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
[Plplot-devel] Greek characters in qt-driver
Alan, In looking over legend things, I've discovered that as of 5.9.7 (and probably also 5.9.6 but I only have 5.9.5 built) there have been a few changes to the hershey-unicode mappings that don't work with the qt driver (but are ok with the xcairo one). I presume this is down to my local font holdings. I append below the summary and workaround I sent internally to my team in order to get our software to display the relevant characters. It looks like for some characters you have decided to pick them not from the standard Greek family ( 0x03a,b,c ) but a variant (0x03d,f). I run an OpenSuse 11.1 system. Gucharmap shows both the symbols and alternatives, and the xcairo driver finds them, so I guess they reside somehow on my system but not accessed by my version of qt (4.5.3). I don't know if you want this submitted as a bug, or if your own systems do better. Let me know... Regards, Steve [ snip ...] Some Greek characters have been moved in plplot to what I presume they find more appealing alternatives. The escapes in question include #gU and #gh (capital Upsilon and lower case theta respectively). Additionally there are two more characters, lunate epsilon and a variant of lower case phi, that can be invoked by plsym but don't work for me. This appears to be a shortcoming in qt, as the Cairo drivers can find them. As before, the "fix" involves changing entries in plhershey-unicode.h: Hershey numbersplplot5.9.7 unicode change to this 46, 546 0x03d2 0x03a5 Upsilon 534 0x03d1 0x03b8 theta 98, 684, 21840x03f5 0x03b5 epsilon 686, 21860x03d5 0x03c6 phi variant -- +---+ Professor Steven J SchwartzPhone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett LaboratoryE-mail: s.schwa...@imperial.ac.uk Imperial College LondonOffice: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +---+ -- 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
