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 __________________________ ------------------------------------------------------------------------------ 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
