Re: [Plplot-devel] changes to plptex3

[Hazen Babcock]

On Aug 23, 2008, at 9:01 PM, Alan W. Irwin wrote:
On 2008-08-23 17:18-0400 Hazen Babcock wrote:

I agree that this (3D text) problem exists and it is pretty easy  
to see if you also draw circles on the plot. However I am not so  
sure what to do about it. [...]In the case of 2D text we are not  
stretching or contracting the baseline of the text to allow for  
the relative x-y scales of the plot.

I confirmed this with the attached 2D test version of xw28.py with  
xscale
very different from yscale.  What is essentially going on is the  
characters
are written in their own semi-independent coordinate system with the
character spacing in the direction of writing a constant when  
expressed in
device coordinates.  So the "n" in revolution describes a 2D circle  
rather
than an ellipse regardless of x or y scale.  And if the viewport is
rectangular, the "n" in revolution still describes a 2D circle.  I  
think
this 2D behaviour is fine so I would like to get as close to that as
possible in the 3D case, and it turns out (see below) we have that  
ideal
behaviour for -dev xcairo, but not quite yet for -dev xwin.

(out of order) If you take an extreme example where you've almost  
gone back to a 2D plot with azimuth = altitude = 5 then you will  
see the text makes a nice circle but if it is to fit properly in  
the bounding box then it should in fact be an oval. In the case of  
2D text we are not stretching or contracting the baseline of
the text to allow for the relative x-y scales of the plot. Do we  
want to do
this with 3D text?

That's an excellent last question. Indeed, the 2D case has clarified
my thoughts, and I think you should always expect to see the text  
make a
nice circle (I confirm that it does) at low alt, az even if the box
is rectangular (like it normally is).

So to my mind the low alt, az behaviour is fine, and the question  
is whether
we have the correct behaviour at other alt, az. One way to test  
that is to
make sure the effective box is square at low alt, az and change the
character size so the circular "revolution" text is nicely  
inscribed by that
square.  Then as alt and az are changed, the text should continue  
to be
nicely inscribed by the 3D square.

I attach a second test case variation of xw28.py that illustrates  
that we do
not quite have the correct behaviour for arbitrary alt, az.  (I have
adjusted plvpor and plwind arguments so that the x and y  
coordinates have
the same range.  You also need to run this test with "square"  
geometry,
e.g., -geometry 600x600 to assure a square box at low alt, az.  You  
may
also have to adjust charsize to get an exactly inscribed box for both
-dev xwin and -dev xcairo since your screen resolution is probably  
different
than mine.)

The attached version has

alt=0.1
az=0.1

I run this test by editing the test version of xw28.py to adjust  
charsize (appropriate to the device driver) and alt, az, and then  
running
either

./x28 -dev xwin -geometry 600x600

or

./x28 -dev xcairo -geometry 600x600

in the _installed_ examples/python directory.

I hope you have python available so you can run the same tests, but  
if not
it should be fairly straightforward to adjust the C version of the  
example
to give "inscribed square" results.

In fact, for the 3D test case, the correct behaviour is seen as you  
vary alt
from 0.1 to 80.1 for fixed az=0.1 for both -dev xwin and -dev  
xcairo. And,
if you do the same sequence in az for fixed alt=0.1, you get good  
behaviour
as well for -dev xcairo.  I am sure you will agree with me that  
this is
greatly encouraging news.

However, the az sequence gives slightly incorrect behaviour (some  
parts of
the "n" slop outside the 3D square at certain angles, and the expected
angular symmetry in how close the "n" comes to the box is slightly  
lost) for
-dev xwin.

If you have -dev xwin available on your platform, I hope you can  
verify the
slightly bad behaviour I see.  If not, I can send you a  
screenshot.  IIRC,
-dev xcairo takes a different PLplot core code path than -dev xwin  
so you
can get correct 3D text results for one but not the other (which  
appears to
be the case here).

Now that I've finally figured out how to run the python examples you  
sent (thanks for the help here) I've can verify what you are seeing.  
To pick an example, at alt = 0.1, az = 22, it looks to me like (for  
the xwin driver) the horizontal and vertical text is properly drawn  
but the text slightly above (and slightly below) horizontal is  
extending outside of the box. Is that what you are referring to? My  
example is attached.

-Hazen

<<inline: awi1.png>>-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel