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!
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
* 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
* 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 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