On 2010-09-11 13:56-0700 Alan W. Irwin wrote:
> If you compare -dev xwin with either -dev xcairo or -dev wxwidgets for
> the current example 4 it is clear there is still a small but
> consistent vertical offset error for the latter two devices.
> I will look further into this side issue.
After running
make -j4 _plplotcmodule
make python_examples xwin cairo qt
try the new version (revision 11171) of test_circle.py, e.g.,
examples/python/test_circle.py -dev xwin
which demonstrates in a simple way that the asterisk is aligned
perfectly for Hershey fonts with -dev xwin wherever the appropriate
encoding method is used ("*" or "#(728)" with plptex, plsym with index
728 or plpoin with index 3).
However, for xcairo and qtwidget the asterisk
with plptex is badly misaligned if encoded as "*" or as the PLplot
unicode encoding "#[0x002a]". For xcairo and qtwidget, plptex with "#(728)" is
slightly misaligned. Why should there be such a big difference in
position alignment between those two encodings which should boil
down to the exact same calls internally for these unicode drivers?
A further puzzle is that for xcairo (with pls->alt_unicode = 1), plsym
and plpoin give slightly different alignments than plptex with
"#(728)". Again, the code paths should boil down to the same thing
internally for this unicode driver if the pls->alt_unicode = 1 code
path is working correctly.
Just to make your head spin a bit more, qtwidget (which uses
pls->alt_unicode = 0) generates consistent (but slightly misaligned)
results for plptex with "#(728)", plsym, and plpoin.
It is pretty clear there is more than one character/symbol unicode
misalignment bug being revealed by these test_circle.py results. For
example, pls->alt_unicode=0 or 1 is probably playing a small role for
the small misalignment cases, but that different code path makes no
noticeable difference for the bad misalignment cases referenced above.
I have put this issue on our bugtracker (bug 3064564).
There are some other PLplot issues that I want to deal with first so
if fixing these bug(s) is strictly up to me, I will probably put off
dealing with this to much later. However, if any one else is
interested in tracking down and fixing these issues before me, we at
least have a good test case with test_circle.py showing the various
kinds of unicode character misalignment problems in great detail.
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
__________________________
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
