Hi Steve: On 2010-06-05 20:01+0100 Steve Schwartz wrote:
> Hi Werner, > > On Thu, 2010-06-03 at 20:12 +0100, Werner Smekal wrote: >> For so much symbols I would suggest to use the hershey fonts for >> symbols >> with >> >> pls->dev_hrshsym = 1; >> >> text will be drawn still nicely. But I'm sure qtwidget should be as >> fast >> as xcairo or close to, so if the 7.5 second are ok for you, I would >> definitely look how text plotting is managed in xcairo and in >> qtwidget. > > Thanks for this; it sounded like a sensible idea, but after extensive > trials, the result is mixed. I attach for your amusement the result of a > variety of trials for various different interactive devices (xwin, tk, > xcairo, and qtwidget), plotting various symbols (plus sign, circle, > filled dot) in various sizes (plssym(0.0, scale)), and with > plsc->dev_hrshsym set to 0 (unicode) or 1 (use hershey). I also attach > the code I was playing with to do this, which is a hacked and > stripped-down version of x01c. It was compiled using the Makefile in my > examples/c folder. > > Here are some brief conclusions: > > For some plot symbols xcairo is faster (by almost a factor of 10) when > using hershey font for them rather than unicode. I guess this is > Werner's experience. > > However, the qtwidget is actually slower when the hershey fonts are > invoked (about 50% more time). See the entries with green and blue > backgrounds in the attached spreadsheet. The simple filled dot takes 6 > times as long with a hershey font. > > Simple circles are an exception to the above and take the same time > regardless of whether the hershey or unicode fonts are used, and this is > true for all the drivers. Some circles do not currently have a unicode equivalent. Try the -DHERSHEY_FALLBACK=OFF option (see explanation below) to be more sure of what you are getting. > > Generally, the qtwidget driver is significantly slower than the others, > and I guess the attached results suggest that this is internal to qt. > > I also tried plotting to pdf files using cairo and qt. I expected to see > the unicode font containing the symbol in the pdf "properties" list of > fonts, but it isn't. [I removed all the plot labelling which resulted in > a pdf with no fonts required/embeded.] This might not be true any longer, but early versions of the Adobe PostScript and PDF standards only officially recognized Type 1 embedded fonts. So for the psttf device, TrueType fonts are implemented by embedding drawing commands for each glyph directly into the PostScript file that is produced by that device. This doesn't violate the Adobe standard, but I doubt those grouped embedded drawing commands would ever be recognized as official embedded fonts by the Adobe standard. I assume the same is true of PostScript and PDF results produced by the epsqt, pdfqt, pscairo, and pdfcairo devices. As a general comment, the response you get for font tests depends very much on the symbol you pick, what device you are using, and what CMake and run-time options you are using. Both plpoin and plsym are legacy API that were originally designed to access Hershey fonts in various ways. For example, if you pick an "ascii" code number for plpoin, that gets translated internally into a symbol number for Hershey fonts. You can also access that symbol number directly using plsym. For devices that are not unicode aware (such as xwin) the Hershey glyph is found corresponding to that Hershey symbol number and drawn directly by the core PLplot library. For unicode-aware devices (e.g., qtwidget, xcairo) the situation is more complicated. We maintain a table to translate between Hershey symbol number and unicode (UCS4) index value (see fonts/plhershey-unicode.csv), but some Hershey symbols just do not have a Unicode equivalent. If the user sets -DHERSHEY_FALLBACK=OFF (which I recommend for font testing since it does not obfuscate the results so much), Hershey symbols without a unicode equivalent are translated to Unicode blank. However, for your tests you probably used the default -DHERSHEY_FALLBACK=ON which means the Hershey glyph will be used in these situations. That default is the best for ordinary use, but it does tend to confuse test interpretation. I think these further two considerations did not affect your tests, but I will mention them anyway for someone who is reading this thread later. plsc->dev_hrshsym is only set by certain devices. For example, there is no driver option to control that value for either qt or cairo devices. So to be sure to force Hershey in such testing for unicode-aware devices you should set that in your C test code rather than relying on driver options. plsc->dev_hrshsym only affects the plhrsh routine which in turn is called only by plpoin, plpoin3, and plsym, but which is _not_ called by plmtex, plmtex3, plptex, and plptex3. In sum, we have a complex decision tree about whether a Hershey glyph or unicode glyph is chosen for plpoin, plpoin3, and plsym. In contrast, plmtex, plptex, and their 3D counterparts always use Hershey glyphs if the device is not unicode-aware, and otherwise use modern fonts for unicode-aware devices. I hope this explanation of our glyph choosing logic helps you refine the interpretation of your tests. 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 __________________________ ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
