On 2007-09-14 00:48-0400 Hazen Babcock wrote:
> On Sep 13, 2007, at 10:13 PM, Alan W. Irwin wrote:
>> Now I would argue that the screenshot 2 results look like a rotation
>> the axis of the string in the sense opposite to the "b" series, but not
>> expected rotation of the vertical axis of the characters in a plane
>> to the XY plane. So I still think screenshot 2 is an incorrect result,
>> we can argue that one later after the screenshot 1 results are sorted out.
> There isn't much to argue about here, draw the appropriate lines on the plot
> and tell me whether you think the text is parallel to these lines or not.
Sorry about the noise. Devices that give Screenshot 2 are giving the
correct results. I figured this out with another method; I viewed pscairo
results at alt=5, az = 355 which showed I was misinterpreting the results
before as a rotation rather than a skew that indeed keeps the "a" series
letters confined to a plane parallel to the XY axis. The "b" series is the
expected rotation around the axis of the string. As far as I can tell now,
all is right with screenshot 2 and the cairo and aqt worlds. It is nice to
know we have at least one foot on dry land... :-)
(Also note my previous tests of "-dev pdf" silently got switched to -dev
pdfcairo because I had not built Werner's pdf device driver. So probably
that device produces screenshot 1, but I don't know that for a fact.)
>> Also notice, there is a slight problem with the "four" label in
>> screenshot 1 that is produced by plmtex3. It looks slightly rotated
>> the axis of the string compared to the numerical labels for the same axis.
>> The "four" label in screenshot 2 does not have this problem. I don't know
>> whether this is an additional issue or part of the same mess.
> A mess indeed...
> It looks to me like the drivers in the first large set are assuming that the
> transform matrix will only contain values consistent with the text being
> either (1) rotated but sheared to vertical as in the x-y axises of a 3D plot,
> or (2) vertically oriented and sheared as in the z axis of a 3D plot. Fixing
> this issue will involve updating all the drivers in the first large set and
> also PLplot core as xwin, for example, does not render its own text. This
> could be a pretty major undertaking.
The device list that needs fixing is the following: psc, psttfc, svg, png
(and the rest of the gd family), wxwidgets (and probably pdf), gcw, xwin,
tk, pbm, and xfig. Could somebody check wingcc as well?
The three devices after xwin are like xwin and do not render their own text.
They simply let the PLplot core send drawing commands using the Hershey
fonts. This is also true (just checked) for all the devices before xwin when
the -drvopt text=0 option is used.
So the fixes can be separated into a fix for the rendering of the core
Hershey fonts (which should correct text=0 results for the seven drivers
that have that driver option and also correct xwin, tk, pbm, and xfig) and
individual fixes for the seven device drivers listed above with the text=1
driver option. So the work naturally divides itself into relatively small
Thanks, Hazen, for leading the way and providing examples of rendering 3D
strings correctly with the cairo and aqt devices.
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