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

Reply via email to