> One issue I did note is that the alignment between the cross from
> plpoin and plstring is slightly different. (I noticed this by accidently
> leaving the plpoin call in as well as the plstring one).
>
> I haven't investigated further yet to know which one is "right" but
> it would be worth a look.
>

Hi Andrew:

I have changed the subject to alignment for obvious reasons.

I have been keeping track of such alignment issues with
examples/python/test_circle.py.  Would you add at least a plpoin and
plstring page to that example with the cross?

Here is the current status with -dev xwin.

Of course, the two pages, "Large Circle + Light Diagonal Cross with
plptex" and "Plplot Encoded Unicode Indexed Asterisk with plptex" do
not work for this non-unicode device driver. "Ascii asterisk with
plptex" and "Plplot Encoded Hershey Indexed Asterisk with plptex"
produce a yellow vertical which is slightly misaligned with the red
vertical behind it.  The next two pages, "Asterisk with plsym" and
"Asterisk with plpoin" produce a slightly different alignment, then
"Plplot Encoded Hershey Indexed Asterisk with plstring" goes back to
the original alignment.  These are all such subtle effects that they
might be dismissed as the result of roundoff error in the 16-bit
internal representation of PLplot positions, but I am not entirely
sure of that interpretation, and you may find a different story if you
repeat the asterisk experiments with a cross instead.

Here is the current status for the unicode-aware -dev qtwidget and
-dev xcairo.

"Large Circle + Light Diagonal Cross with plptex" produces a
"crumpled" circle for the largest three magnifications but the others
are fine for -dev qtwidget.  I reported this as a Qt bug years ago to
trolltech but never got a response, and I would be interested if
anyone else here gets a good result (round circles for the highest
three magnifications) for any version of Qt.  -dev xcairo produces
round circles at all magnifications.

According to the gucharmap display for generic sans (which is
transformed to DejaVu Sans on my system), the "Light Diagonal Cross"
symbol has excellent vertical and horizontal centering within its box
so that has been the symbol I used to tune up the vertical alignment
of both the qt and cairo devices.  You can see the results of that
tuning on this page with the intersection of the various magnified
crosses in complete agreement in position. In contrast, you can also
see how the center of the circle drifts closer to the bottom (i.e.,
shows spurious alignment issues) as it is magnified, but that is
because it is not cleanly vertically centered in its box according to
the gucharmap display for DejaVu Sans.  (By the way, if you try this
example with the wxGC version of -dev wxwidgets you can see from how
the center of the crosses drift with magnification demonstrating that
both the vertical and horizontal positions need tuning for at least
this version of -dev wxwidgets.)

The asterisk pages of this example demonstrate consistent alignment
between -dev xcairo and -dev qtwidgets. "Ascii asterisk with plptex"
and "Plplot Encoded Unicode Indexed Asterisk with plptex" show the
asterisk moving upward with magnification, but the gucharmap display
explains that because the asterisk is centered high in its box (at
least for the DejaVu Sans font).  So I think those results are fine,
and the much better centering you get with -dev xwin for "Ascii
asterisk with plptex"is simply because the Hershey fonts have a
vertically centered asterisk within its box.

What actually bothers me for -dev xcairo and -dev qtwidgets is the
remaining asterisk pages display consistently centered asterisks in
complete disagreement with the plptex results and my explanation above about
how the asterisk glyph is vertically misaligned within its box
according to gucharmap. What do those text code paths know that plptex
does not know?  Has there been some extra spurious vertical adjustment
in those cases?  Or is there something missing from the plptex
code path that causes misalignment unless you do some extra tuning
for each 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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to