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.schwa...@imperial.ac.uk Imperial College London Office: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
