On 2009-08-19 10:33-0700 Alan W. Irwin wrote:

> On 2009-08-17 23:31-0400 Hazen Babcock wrote:
>
>> Alan W. Irwin wrote:
>>>
>>> ./test_superscript_subscript.py -dev xwin -cmap0 cmap0_black_on_white.pal
>>>
>>> -dev xwin and -dev svg (when the result is rendered with the the
>>> ImageMagick
>>> "display" application) passes this test with flying colours.  Also, -dev
>>> wxwidgets (wxGC) gets the vertical positioning right (although as with many
>>> other examples, there are horizontal spacing issues with wxwidgets for this
>>> example).  The pdf, qt, and cairo devices do not give correct results for
>>> this example. I will take responsibility for dealing with this issue for
>>> the
>>> pdf and qt devices, and I have asked Hazen off-list whether he would be
>>> willing to take responsibility for this issue with the cairo devices.
>>
>> This should be fixed for the cairo driver in v10273, though you might want to
>> tune the offsets a little. The only issue that I can see is that the phi
>> subscript looks unusually low in xcairo vs xwin?
>
> That's a lot better, but I agree there is an issue with the scale of the
> Greek letter offsets (both superscript and subscript).  Can you confirm the
> driver is currently using the span rise tag before the font change
> associated with the Greek letter, but not after?  If that is the case, would
> you be willing to implement repeating the current span rise tag after each
> font change within the string (but before any character is rendered with the
> new font)?  I think that is necessary since a font change potentially
> changes the scale of the fonts and therefore the interpretation of the span
> rise tag. Obviously the driver should continue what it is doing with the
> current span rise tag since there is no guarantee of a font change right
> after a superscript or subscript.  However, I believe that if a repeat span
> rise tag is also put in after all font changes within a string, that might
> well fix the Greek-letter superscript/subscript offset issue.

I did some more testing of superscript/subscript rendering of mixed Greek
and Latin letters for -dev xcairo, and it appears my above hypothesis is not
correct.  If I use Greek letters first (at superscript/subscript level 0)
there is still the same issue; the superscript/subscript Greek letter is
still off by one in its offset.  I then expanded the test for a combination
of Greek and Latin letters at superscript/subscript level 1 (see revision
10312), and I found a peculiar result; as soon as there is a shift to Greek
letters (or probably any change in font) at the superscript or subscript
level, the level interpretation changes by 1 and is uniform from then on
regardless of whether Latin or Greek letters are used.

There is no difficulty with this latest version of the example either for
-dev svg (when viewed by "display") or -dev xwin so I suspect there must
still be some off-by-one logic error in superscript/subscript level in
cairo.c that is causing the issues you can see for this example for -dev
xcairo.  I suggest the best way to debug this is to look carefully at the
complete generated pangoMarkupString just before it is sent to the
pango/cairo libraries.  If that seems fine (i.e., you can explain every
command and there are no changes in rise just before Greek letters occur in
the superscript/subscript), then this must be a bug in how rise is
interpreted by the pango/cairo libraries.  But I hope you do see something
wrong with pangoMarkupString since that is much easier to fix than some
more fundamental issue with pango/cairo.

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
__________________________

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to