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