On 2010-10-02 19:05+0100 Steve Schwartz wrote:

> Alan,
>
> I've just posted a comment to this bug (which I was about to report but
> found you had already stumbled on the problem). I promised to attach a
> file, but since I can't I'll attach them here.

Hi Steve:

I suggest you look at gucharmap glyph results (whose individual glyphs
can be expanded to be even as large as your monitor's screen) to help
sort out _part_ of what is going on with TrueType font alignment. 
Some glyphs for the generic sans font (the one used by default by
PLplot) do seem to have perfect alignment such as the light diagonal
cross. That is why I use that symbol first in test_circle.py to test
the overall alignment of qt and cairo devices. Other symbols are
poorly aligned in gucharmap.  For example, there is a slight
misalignment of large circle which shows up in the first page of the
test_circle.py example.  The misalignment of asterisk is much worse as
can be seen in gucharmap and also pages two and three of the example.
I ascribe the Hershey font misalignment issues you have reported to a
similar cause since in general our Hershey font path is our gold
standard for being extremely well debugged for misalignment issues.
That conclusion is less certain for the ps misalignment issues for
Type 1 fonts that you have found, but I suggest you should ignore that
issue for now because the TrueType issue is much more important
(affects many more devices).

My TrueType misalignment bug report is related to the fact that the
subsequent pages of test_circle.py show _other_ methods of rendering
that asterisk don't give consistent alignment with pages 2 and 3.
(Actually the alignment is much better than for pages 2 and 3, but I
think that is two or more wrongs making a right since the misalignment
given in pages 2 and 3 is consistent with the misalignment shown by
gurcharmap.)

In sum, I think the alignment results shown for test_circle.py for
pages 1, 2, and 3 are correct because they agree with the gucharmap
(mis)alignment, but the subsequent pages of that example show some
gross alignment inconsistencies with pages 2 and 3. That result is
puzzling because all those different code paths have many parts which
are identical and the rendered result is also meant to be identical.
So there must be one or more bugs in those code paths exercised by
pages 4 and beyond.

Our next release cycle is going to be quite full for me since I will
be dealing with legend issues as well as possibly some other issues
(such as filling, gradient, and time improvements) I have been putting
off. So I would welcome your group's help in debugging that python
example to follow the various code paths involved to see why pages 4
and beyond produce vertical alignment of the asterisk which
is inconsistent with the vertical alignment shown by pages 2 and 3.
("gdb python examples/python/test_circle.py" should work since python
dynamically loads the PLplot library which in turn dynamically loads
the device.)

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

Reply via email to