From: Steve S. <s.s...@im...> - 2010-06-29 19:36:53
|
Is is just me, or have others noticed that plot symbol 17, which is supposed to be a filled circle, is a small square using the unicode-based drivers (at least qt and cairo which are the ones I have) but are stroke-filled circles using Hershey drivers (xwin, tk, etc. including setting plsc->dev_hrshsym = 1 for the qt and cairo drivers)? This isn't easy to see in Example 06 until you magnify the result (you can grow the qt window on screen), but easy to see if you code a trivial example. In exploring, I have also discovered that the qt driver doesn't treat plsc->dev_hrshsym = 1 and plsc->dev_unicode = 0 in the same way. Using the latter in a loop with symbol 18 (filled star) crashes sample code, whereas the former runs as expected. Sorry, I know I should send some sample code (and I can send my hacked x01c if someone wants it) and some output from a debugger, but I'm pressed for time. Regards, Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2010-06-29 22:07:15
|
On 2010-06-29 20:38+0100 Steve Schwartz wrote: Hi Steve: Unless someone else beats me to it, I will attempt to answer your symbol 17 question later once I have had time to investigate. Meanwhile, your further question below is something I can answer immediately. > In exploring, I have also discovered that the qt driver doesn't treat > > plsc->dev_hrshsym = 1 > > and > > plsc->dev_unicode = 0 > > in the same way. Using the latter in a loop with symbol 18 (filled star) > crashes sample code, whereas the former runs as expected. Sorry, I know > I should send some sample code (and I can send my hacked x01c if someone > wants it) and some output from a debugger, but I'm pressed for time. Normally plsc->dev_unicode = 0 and plsc->dev_unicode = 1 should be set only by drivers and not by code outside drivers because it indicates whether the driver is implemented for Hershey fonts or modern fonts. Thus, when you forced the issue by setting plsc->dev_unicode = 0 for a driver that had specified plsc->dev_unicode = 1, I am not surprised you got crashes. Of course, it should be relatively trivial to implement Hershey capability as an option for any driver that is currently advertises itself as plsc->dev_unicode = 1. For example, I think this has actually occurred for the gcw device. However, I would view that as a retrograde step since in general, modern fonts have many more glyphs available than Hershey fonts. Thus, I would prefer to fix any problems (e.g., the symbol 17 problem you just found) when using modern fonts. 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-06-29 23:05:15
|
On Jun 29, 2010, at 12:38 PM, Steve Schwartz wrote: > Is is just me, or have others noticed that plot symbol 17, which is > supposed to be a filled circle, is a small square using the > unicode-based drivers (at least qt and cairo which are the ones I > have) > but are stroke-filled circles using Hershey drivers And they vastly blow up the size of a Postscript file with lots of plotted points. I hate them. And the "circles" are merely few-sided polygons--more wasted strokes. Jerry > (xwin, tk, etc. > including setting plsc->dev_hrshsym = 1 for the qt and cairo drivers)? > > This isn't easy to see in Example 06 until you magnify the result (you > can grow the qt window on screen), but easy to see if you code a > trivial > example. > > In exploring, I have also discovered that the qt driver doesn't treat > > plsc->dev_hrshsym = 1 > > and > > plsc->dev_unicode = 0 > > in the same way. Using the latter in a loop with symbol 18 (filled > star) > crashes sample code, whereas the former runs as expected. Sorry, I > know > I should send some sample code (and I can send my hacked x01c if > someone > wants it) and some output from a debugger, but I'm pressed for time. > > Regards, > Steve > > -- > +-------------------------------------------------------------------+ > Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 > Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 > The Blackett Laboratory E-mail: s.s...@im... > Imperial College London Office: Huxley 6M67A > London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs > +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2010-06-30 02:20:22
|
Hi Jerry: You obviously had some issues you discussed below which were bothering you. In response, I have asked you to be more precise about what you mean, and I have also given you some additional PLplot font/glyph background which hopefully you will find useful. On 2010-06-29 16:05-0700 Jerry wrote: > > On Jun 29, 2010, at 12:38 PM, Steve Schwartz wrote: > >> Is is just me, or have others noticed that plot symbol 17, which is >> supposed to be a filled circle, is a small square using the >> unicode-based drivers (at least qt and cairo which are the ones I >> have) >> but are stroke-filled circles using Hershey drivers > > And they vastly blow up the size of a Postscript file with lots of > plotted points. I hate them. And the "circles" are merely few-sided > polygons--more wasted strokes. Who is "they"? If you are referring to drivers with Hershey fonts (or with Hershey fallbacks), I think your remarks are well taken; for filled symbols I don't think our Hershey routines can take advantage of hardware filling so in effect you end up with slow/expensive/bad-looking software filling for the glyph instead. In contrast, I believe the modern fonts will take advantage of hardware filling as much as possible for filled glyphs. Of course, this is normally not a major factor for Hershey fonts since so few glyphs are filled in that case. You also referred to "wasted strokes" in PostScript files. Which PostScript devices are you referring to here? To give you some background, glyphs are ultimately defined by filled or open curves, and I think both TrueType and Type 1 modern fonts probably do a much better job than the Hershey fonts in representing those curves in a compact way. A further consideration is both the cairo and Qt libraries store TrueType glyphs in the resulting Postscript files as a series of fundamental PostScript commands rather than as the official compact form (since traditional PostScript does not understand the compact TrueType glyph representation). In contrast, my understanding is -dev psc does not even embed the compact Type 1 fonts that it uses, and instead it leaves it up to the PostScript interpreter at rendering time to provide those (well-known) Type 1 fonts. >From my experience with research plots when I tested this some time ago, -dev pscairo files were substantially larger than the corresponding -dev psc files and I attributed that result to the embedded series of PostScript commands to represent TrueType glyphs for -dev pscairo (and presumably -dev epsqt) versus no embedded fonts at all in the -dev psc results. Anyhow, I was happy to pay the price of a larger PostScript file size with pscairo (and presumably epsqt) because -dev pscairo depends on Type 1 fonts which have an extremely limited set of mathematical symbols (in fact, so limited that by default -dev psc uses Hershey fonts to complete examples 6 and 7) while thousands of high-quality math symbols are available with -dev pscairo and -dev epsqt. I also tried to illustrate that Type 1 versus TrueType difference when I implemented example 23 some time ago. All of -dev psc, -dev pscairo, and -dev epsqt do well for the first four pages of that example which were especially chosen to represent the limited set of math glyphs available with Type 1 fonts. However, -dev psc gives almost blank results for the next 7 pages of math symbols while -dev pscairo, and -dev epsqt give almost complete coverage of the mathematical symbols for those 7 pages at least for the usual mix of TrueType fonts that tend to be installed on Linux systems. (Which reminds me I should look at example 23 results for -dev pscairo and -dev epsqt for the Wine platform. I believe that platform only uses standard Windows fonts so it will be interesting to see how well those do for example 23 versus the virtually complete glyph coverage you get on Linux.) In sum, our pscairo and epsqt devices give the best PostScript results not only in terms of the enormous number of glyphs available, but also in looks (including hinting for the case where you are looking at results displayed on a monitor). I regard -dev psc as second best by far because it sometimes must fall back to ugly Hershey fonts for certain symbols, but it does have the big advantage that it is self-contained (no dependencies on external libraries) so it is great for quick and dirty cross-platform testing, and also for the case where you have no need of any symbols other than those provided by Type1 fonts. (You may get the impression you have sufficient symbols with -dev psc, but that is normally because of the Hershey symbol fallback. If you want to see the true situation, use the -DHERSHEY_FALLBACK=OFF cmake option. Also, for the pdf and ps devices (which are the only devices to default to hrshsym=1 because of the Type 1 fonts limitations), use the run-time option, -drvopt hrshsym=0. The glyphs that are present in Examples 6 and 7 look much better when using that driver option for those devices, but at the expense of many missing glyphs. I hope this background (which is an admittedly complicated story) helps you to figure out the reason(s) for the issues you were discussing. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-06-30 00:20:41
|
On 2010-06-29 20:38+0100 Steve Schwartz wrote: > Is is just me, or have others noticed that plot symbol 17, which is > supposed to be a filled circle, is a small square using the > unicode-based drivers (at least qt and cairo which are the ones I have) > but are stroke-filled circles using Hershey drivers (xwin, tk, etc. > including setting plsc->dev_hrshsym = 1 for the qt and cairo drivers)? Thanks for bringing this issue to our attention. It's sharp-eyed users like you that help to push the quality of PLplot results. Here is how I investigated this issue. First I ran examples/c/x06c -dev qtwidget and expanded the window by repeatedly moving the window down and to the left by dragging with alt+left mouse and then grabbing the upper right corner to expand what is left on the screen. The result was example 6 has a nicely filled circle on my system, and I bet if you go through that exact same exercise you will verify that on your system (see further explanation below why you should get filled circles in certain cases like example 6). If I uncomment the diagnostic output in line 154 of plsym.c, then plploin code, sym = 17, 143 is obtained for the initial compact Hershey indexing case, and plploin code, sym = 17, 850 is obtained for the subsequent 4 extended Hershey font indexing cases. In fonts/plhershey-unicode.csv we have the lines 0x2219,143,1 0x2219,850,0 So both 143 and 850 Hershey index correspond with Unicode 0x2219 for device drivers like qt and cairo which use unicode fonts. If you look that up with the (highly recommended!) gucharmap application, 0x2219 corresponds to the bullet operator. The glyph displayed by gucharmap by default for that index is also round for my system fonts. To see that without question, make the gucharmap text size large by increasing the number in the right-most command box (right next to the italic toggle switch). I was using the generic Sans fonts (just like qt and cairo do) which resolved on my system to finding the bullet glyph in the DejaVu Sans fonts. (You can tell the exact font used for rendering with gucharmap by right clicking on the glyph.) I also got the same glyph for the italic case, but for the bold case (generated by toggling the bold switch) it came out square! For the generic Serif fonts (which resolved to DejaVu Serif) the result was a filled circle regardless of italic or bold toggles. So, my guess is your test was using bold Sans fonts (if you system fonts were similar to mine) for your simple test code, but example 6 does not have bold which is why I predicted above you will see a round symbol in that case (assuming your system fonts are similar to mine). Anyhow, regardless of what fonts are installed on the system, the important issue here is gucharmap shows that some of the unicode index 0x2219 positions in some modern fonts have a filled square glyph rather than a filled circle (which seems reasonable because some people like square bullets rather than round ones in text lists). So clearly, 0x2219 is a poor choice for unicode glyphs corresponding to Hershey "ascii" index 17 or Hershey indices 143 (compact) and 850 (extended). The gucharmap GUI has cross references in the character details (did I say this is a highly recommended app?) which lead me to the "bullet" glyph (0x2022, as opposed to 0x2219 for the "bullet operator" glyph). All fonts appear to have round glyphs for the bullet on my system, and furthermore, the alias for bullet (using the character details) is "black small circle" which is what we want those Hershey symbols to correspond to. So I have made the consistent change from 0x2219 to 0x2022 in fonts/plhershey-unicode.csv (revision 11083). Please try that, and let me know if it fixes the issue that you found. 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 __________________________ |
From: Steve S. <s.s...@im...> - 2010-06-30 12:47:52
|
Alan (with apologies for top-posting, but your original is a bit wieldy) I have verified that unicode 0x2022 works fine, and indeed is better for me in that it is bigger than the "bullet operator". I didn't fetch/build your svn version, but I did hack plhershey-unicode.h by finding the translation of hershey 850 and changing the value from 0x2219 to 0x2022, rebuilding our qsas software, and get filled circles as predicted. [I know I shouldn't edit plhershey-unicode.h, but it was the quickest route for me. I'm just a born hacker.] FYI, my system (OpenSuse 11.1) uses Arial for its default Sans (as revealed by right-clicking the glyph on the excellent gucharmap app :-)) ) which has a square for all variants of 0x2219, while as you have reported the DejaVu Sans flips from square to circle. Finally, on the matter of fiddling with plsc->dev_unicode, I agree that users shouldn't do this within their own code, or more correctly that users should stick to the public API. I was just a bit surprised that the same code ran fine with symbol 17 and crashed on the 2nd loop when I replaced 17 by 18. Thanks for the quick diagnosis and cure. Yours Steve On Wed, 2010-06-30 at 01:13 +0100, Alan W. Irwin wrote: > On 2010-06-29 20:38+0100 Steve Schwartz wrote: > > > Is is just me, or have others noticed that plot symbol 17, which is > > supposed to be a filled circle, is a small square using the > > unicode-based drivers (at least qt and cairo which are the ones I have) > > but are stroke-filled circles using Hershey drivers (xwin, tk, etc. > > including setting plsc->dev_hrshsym = 1 for the qt and cairo drivers)? > > Thanks for bringing this issue to our attention. It's sharp-eyed users > like you that help to push the quality of PLplot results. > > Here is how I investigated this issue. First I ran > > examples/c/x06c -dev qtwidget > > and expanded the window by repeatedly moving the window down and to the left > by dragging with alt+left mouse and then grabbing the upper right corner to > expand what is left on the screen. The result was example 6 > has a nicely filled circle on my system, and I bet if you go through > that exact same exercise you will verify that on your system (see further > explanation below why you should get filled circles in certain cases > like example 6). > > If I uncomment the diagnostic output in line 154 of plsym.c, then > > plploin code, sym = 17, 143 > > is obtained for the initial compact Hershey indexing case, and > > plploin code, sym = 17, 850 > > is obtained for the subsequent 4 extended Hershey font indexing cases. > > In fonts/plhershey-unicode.csv we have the lines > > 0x2219,143,1 > 0x2219,850,0 > > So both 143 and 850 Hershey index correspond with Unicode > 0x2219 for device drivers like qt and cairo which use unicode fonts. > > If you look that up with the (highly recommended!) gucharmap application, > 0x2219 corresponds to the bullet operator. The glyph displayed by gucharmap > by default for that index is also round for my system fonts. To see that > without question, make the gucharmap text size large by increasing the > number in the right-most command box (right next to the italic toggle > switch). I was using the generic Sans fonts (just like qt and cairo do) > which resolved on my system to finding the bullet glyph in the DejaVu Sans > fonts. (You can tell the exact font used for rendering with gucharmap by > right clicking on the glyph.) I also got the same glyph for the italic case, > but for the bold case (generated by toggling the bold switch) it came out > square! For the generic Serif fonts (which resolved to DejaVu Serif) the > result was a filled circle regardless of italic or bold toggles. > > So, my guess is your test was using bold Sans fonts (if you system fonts > were similar to mine) for your simple test code, but example 6 does not have > bold which is why I predicted above you will see a round symbol in that > case (assuming your system fonts are similar to mine). > > Anyhow, regardless of what fonts are installed on the system, the important > issue here is gucharmap shows that some of the unicode index 0x2219 > positions in some modern fonts have a filled square glyph rather than a > filled circle (which seems reasonable because some people like square > bullets rather than round ones in text lists). So clearly, 0x2219 is a poor > choice for unicode glyphs corresponding to Hershey "ascii" index 17 or > Hershey indices 143 (compact) and 850 (extended). > > The gucharmap GUI has cross references in the character details (did I say > this is a highly recommended app?) which lead me to the "bullet" glyph > (0x2022, as opposed to 0x2219 for the "bullet operator" glyph). All fonts > appear to have round glyphs for the bullet on my system, and furthermore, > the alias for bullet (using the character details) is "black small circle" > which is what we want those Hershey symbols to correspond to. > > So I have made the consistent change from 0x2219 to 0x2022 in > fonts/plhershey-unicode.csv (revision 11083). Please try that, and > let me know if it fixes the issue that you found. > > 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 > __________________________ -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |