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