The svg device driver requires a linear transformation (with
empirically determined coefficients) to obtain correct vertical positioning
of unicode glyphs.  A scale factor is also required to obtain the correct
size of glyphs. To help determine those coefficients I have put together a
test python script (revision 9763, test_circle.py) to test centring of two
unicode glyphs (a circle and a cross) as a function of character size.
If the offset coefficient multiplying the glyph size is incorrect, then as
the glyph size is increased the offset will get worse and worse.  OTOH if
the constant offset coefficient is incorrect, then the relative shift caused
by this will be largest for the smallest glyph sizes.

When I ran the test script using cairo devices, I found, much to my
surprise, glyph offsets showing up. This issue was more severe for the
circle than for the cross.  I then confirmed exactly this issue for
gucharmap as well (a libcairo dependent-application that displays unicode
glyphs within boxes).  In fact gucharmap showed many circular symbols with
offsets both above and below the center of the box for the default Sans font
on my system (DejaVu Sans).  There was also a relatively obscure Korean font
(undotum) that didn't have such offset problems for certain circled number
glyphs.  I assume from the results of these tests that the DejaVu Sans fonts
are implemented properly for Linux, and libpango/libcairo and gucharmap and
the PLplot cairo device driver which depends on those libraries are
rendering the unicode glyphs with the correct vertical position following
the desire of the artists behind the font in question.  I further assume in
the undotum case, the artists wanted perfectly centred circular glyphs, but
in the DejaVu Sans case, the artists wanted a variety of vertical offsets 
for the large variety of circle variants to make the result more
aesthetically pleasing to them. However, these "intentional" offsets make it
a bit more complicated to calibrate the offset coefficients for the svg
device driver.

I ended up adjusting the glyph size ratio and the two offset coefficients in
svg.c (revision 9764) to match closely the "intentional" offsets displayed
by the cairo devices for test_circle.py.  I then double-checked the -dev svg
results for example 2, and the offsets were perfect in that case as well. I
am currently doing an additional adustment of the justification offsets for
-dev svg, but that work should complete my current effort for -dev svg.

I also have tested glyph offsets for other unicode enabled devices using
test_circle.py.  As you would expect, -dev psttfc gives very similar results
to -dev pscairo (since -dev psttfc depends indirectly on libpango/libcairo).
However, other results are not so good. -dev gcw gives a different offset
pattern than -dev svg, -dev pscairo, etc. -dev png (and presumably the other
gd-related devices) gives horrible looking offsets for both test_circle.py
and example 2.  So does the "agg" variant of -dev wxwidgets.

I think the agg variant of wxwidgets depends on plfreetype as does the
gd-related devices so I think the offset problems mentioned above for both
wxwidgets and -dev png are due to an offset issue with plfreetype.  So that
is one more addition to the known plfreetype issues which include crude font
selection by directory and file name and bad rendering of CTL (Complex Text
Layout) languages like Arabic, Hebrew, Hindi, Thai, etc.

Werner, I assume you have ready access to the "best" version of wxwidgets
which depends on the latest wxwidgets development libraries rather than
libagg.  Those latest wxwidgets development libraries are not available for
Debian, and I don't have time/expertise to build them for myself.

Could you confirm that when you run that "best" version of -dev wxwidgets
you get the same offset and glyph size results as for -dev xcairo for the
second example and for examples/python/test_circle.py run in the installed
examples tree?  If you are unable to confirm that, please send me the
screenshots of your tests of the "best" version of wxwidgets against
-dev xcairo.

After the justification offset calibration mentioned above for -dev svg is
completed, my next move is to test (and calibrate if necessary) the qt
device driver glyph offsets using example 2 and
examples/python/test_circle.py.

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
__________________________

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to