On 2009-04-08 14:35+0100 Alban Rochel wrote: > Hi Alan, > > Experimenting around this bug, I've found a way to get everything > working properly (at least on my system), though I do not understand > clearly what's going on. If I set explicitly a family name for the > fonts, the bounding boxes sometimes get messed up for some characters: > theta gets a smaller bounding box than the rest of the characters and > gets glued on the top boundary of its box whereas it has a large margin > beneath it for example (hence the offset). > > However, the StyleHint parameter is used by the Qt font engine to > determine which font to use in case the explicitly defined family is not > available. Defining the good style hint and asking Qt to get a > non-existing font (I called it "foo"), thus letting it choose (and > parameter something with?) the fonts, everything seems to work fine: > Sans-serif, Serif and Monotype fonts are used where required, and no > offset is noticed on my system (OpenSuse 11.1, Qt 4.4.3). > > I've compared the results of the whole set of tests between qtwidget and > xcairo, they look similar. I've reduced a little the Qt font size to > better match Cairo's (1.6 factor to 1.45). > > I propose the attached patch based on revision 9796. Due to the rather > fuzzy nature of the bug (and the proposed fix), reports on other systems > are welcome!
Hi Alban: I didn't like the name "foo" since someone is bound to use that family name for a font some day, if they haven't done so yet. I found using an empty string for the name worked just as well. I also changed the programming style a little so case and number were always separated by a blank. According to the documentation of the font-matching algorithm at http://doc.trolltech.com/4.5/qfont.html#fontmatching, the only method of getting styleHint() to be followed is if the font family cannot be found. So I think the "trick" of using a non-existent (empty) fontname is exactly what we should be doing. I should have thought of this weeks ago when I first read that documentation, but I think you have independently found the correct solution now. Preliminary tests looked really good. For example, I confirm the offset problems are (mostly) gone. I suspect this has more to do with your dropped empirical corrections to the glyph bounding box rather than modifications to the glyph finding, but I don't care; it works! So I committed your slightly modified patch as revision 9797. I repeated my extensive tests from before comparing *.epsqt with *pscairo, *.pngqt with *.pngcairo, and *.svgqt with *.svgcairo results for all standard examples. That is a huge number of plots to look at, but I thought this care was necessary since the above commit has some fundamental changes including a basic change in font size. The short story from these extensive comparisons is there are issues, but all can be ascribed to Qt4 so I think qt is now working as well as can be expected on my Debian Lenny/Qt-4.5.0 platform, and it can only get better as Qt4 gets better. You are apparently also happy with the results of your extensive tests on your OpenSuse/Qt-4.4.3 platform so I am tempted to generalize that the qt device driver is fine now on all Linux platform, but we need tests from other Linux distros to confirm that. We also need volunteers to do testing of the qt devices on Mac OS X and Windows. Here are my notes about the qt changes I found from my extensive tests for revision 9797. * Glyph selection is now identical to that of the cairo device driver (except for svgqt, see below). So the previous use of definite font family names was really messing us up. * The glyph offset issues noticed before (mostly for Greek letters but there were a few more as well) for examples 3, 7, and 23 are gone. That is a substantial improvement. * There are still some vertical alignment issues of the "Peace" word as a whole for some of the languages in example 24, but those shifts are smaller than before, and I assume they are due to problems with Qt itself not interpreting position information from the exotic fonts for these languages quite as correctly as libpango/libcairo does it. * Example 9 contour labels have a larger offset from the contour line for qt than they do for cairo. I didn't notice this before, but it may have been there. In any case I am not sure which one is better so I don't think we have to be concerned except to note there is a difference. * Font size agreement with cairo is improved for some examples (e.g., ex 1), but made a bit worse (e.g., ex 2) for others. It appears the new font size is an acceptable compromise. * ./test_circle.py still gives a "squashed" result for the circular symbol at all sizes which I attribute to Qt problems. The size discrepancy between the qt and cairo result is now within acceptable bounds (see comment just above) and the centring for both is fine. * Example 31. No change here. The first page has a small artifact (dark edge on the left-hand side of the second box) for epsqt, but this artifact does not show up for any other qt device (including the pdfqt device) or cairo device so I assume it is due to a rendering bug in the PostScript back-end for Qt4.5. Page 2 of example 31 looks bad for all our devices (because PLplot approximates gradients with a series of rectangles whose edges don't overlap quite right). By chance (I think) Page 2 looks considerably worse for qt than for cairo. * svgqt is still a bit problematic even for Qt4.5. + Unlike the other devices, all font-hints are ignored. This is definitely a bug in Qt4.5. What it should do is a font lookup just like for the other devices following the hints, but instead the svg file ignores hints and simply uses the empty font family string. The ImageMagick display app recovers from this lack of font family information by using a default sans font, but that is not always the right result as can be seen from the last pages of example 23 where you always get sans when the example wants serif and/or monotype. + unlike other devices, horizontal offset is problematic. For example 1, the exponent in the y label is fine, but there is a huge gap for the exponent that appears in the title (regardless of whether you use display, konqueror or firefox to view the result). The gap was smaller (just a single extra blank inserted before the exponent) for earlier versions of qt, but still there. So I think some of the empirical bounding box corrections we had before which were causing trouble for some of the other devices were partially covering up for Qt4.5 svg horizontal spacing issues. Actually, as I recall, Qt4.5/svgqt has much improved horizontal and vertical offsets compared to Qt4.4/svgqt so I assume further svg offset corrections for Qt4 will completely solve this issue. Therefore, I think we should not do anything to specially correct this svgqt offset problem at the qt device driver level. + text clipping does not work for svgqt although it does for all other qt devices I have tested. I guess it is always possible this could be a qt device driver issue, but from what I see all this stuff is done in a generic way for all devices so I assume this issue is due to Qt4 svg backend problems rather than qt. > > For your information, Imperial College closes tonight for Easter and > re-opens Wednesday next week. I will be away during this period. Well, I hope you read your e-mail during this time so you will know that your patch was a success! :-) 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 __________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
