From: Alan W. I. <ir...@be...> - 2009-04-06 07:54:03
Attachments:
greektest-1.0.1.tar.gz
test.png
|
Hi Alban: I have a contact who was kind enough to put together a simple Qt application for me that wrote unicode text to a GUI text box. I changed that application (by brute force since my C++ skills are not the best) to specifically use the text string r(theta)=sin 5theta, where "theta" in the above equation stands for the actual Greek letter, unicode 0x398. The point of this example was to prepare a simple test case for a Qt bug report. I was fully expecting to see a misalignment of the theta relative to the Latin letters just like we get in the title to Plplot example 3 with any of the qt devices. However, that expectation was wrong! In fact, the simple Qt text application lines up the theta perfectly both with Qt-4.4.3 provided by Debian Lenny, and the pre-release version of Qt-4.5.0 that you can download from trolltech. I have attached this simple test case as a tarball. To build it, unpack the tarball, cd to the created directory, configure the application by running the "qmake" command, and then run "make" to generate a Qt executable called greektest. When you run that application you will see a nicely aligned result unlike the title rendered by all qt devices for the 3rd PLplot example. (I have also attached the result I get here for -dev pngqt for example 3 which demonstrates the alignment problem.) Because I cannot reproduce the alignment issue with a simple test case, I am beginning to feel there are still text alignment bugs lurking in our qt device driver that affect only a small subset of glyphs in our examples (notably the Greek glyphs and a few more). I plan to change the text attributes in the simple example to be as consistent as possible with the qt device driver. The approach I am taking here is to find a way to replicate the misalignment issue with a simple test case. Once I know how to change the text case to misalign the characters, it should be a small step to do the opposite and fix the qt device driver to align the characters. I will try to deal with this issue in the suggested way before the release, but I have other release-related issues on my plate so my time is limited, and I may not get to it before the release. Also, my approach might not work to find the source of the problem. Thus, I encourage you to work on this issue as well (or completely take responsibility for fixing the issue if it looks like it would be easy for you). If you are agreeable to working on this issue, the first question is can you reproduce the misaligned Greek characters in the title of PLplot example 3 (the theta is roughly half a character height too high on my platform as you can see from the second attachment). Assuming you verify the issue, you may want to take a different debugging approach than the one I discussed above such as experimenting directly with text attributes for the qt device driver until you find a combination that gives good alignment for our example 3 title. If you can do that, I would be happy to follow up with comprehensive tests for all our examples to make sure all known character alignment issues are fixed by your change and there are no alignment regressions. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-04-06 17:28:16
|
On 2009-04-06 00:53-0700 Alan W. Irwin wrote: > Hi Alban: > > I have a contact who was kind enough to put together a simple Qt application > for me that wrote unicode text to a GUI text box. I changed that application > (by brute force since my C++ skills are not the best) to specifically use > the text string > > r(theta)=sin 5theta, > > where "theta" in the above equation stands for the actual Greek letter, > unicode 0x398. The point of this example was to prepare a simple test case > for a Qt bug report. I was fully expecting to see a misalignment of the > theta relative to the Latin letters just like we get in the title to Plplot > example 3 with any of the qt devices. However, that expectation was wrong! > In fact, the simple Qt text application lines up the theta perfectly both > with Qt-4.4.3 provided by Debian Lenny, and the pre-release version of > Qt-4.5.0 that you can download from trolltech. > > I have attached this simple test case as a tarball. To build it, unpack the > tarball, cd to the created directory, configure the application > by running the "qmake" command, and then run "make" to > generate a Qt executable called greektest. When you run that application > you will see a nicely aligned result unlike the title rendered by all qt > devices for the 3rd PLplot example. (I have also attached the result > I get here for -dev pngqt for example 3 which demonstrates the alignment > problem.) > > Because I cannot reproduce the alignment issue with a simple test case, I am > beginning to feel there are still text alignment bugs lurking in our qt > device driver that affect only a small subset of glyphs in our examples > (notably the Greek glyphs and a few more). > > I plan to change the text attributes in the simple example to be as > consistent as possible with the qt device driver. The approach I am taking > here is to find a way to replicate the misalignment issue with a simple test > case. Once I know how to change the text case to misalign the characters, > it should be a small step to do the opposite and fix the qt device driver to > align the characters. > > I will try to deal with this issue in the suggested way before the release, > but I have other release-related issues on my plate so my time is limited, > and I may not get to it before the release. Also, my approach might not work > to find the source of the problem. Thus, I encourage you to work on this > issue as well (or completely take responsibility for fixing the issue if > it looks like it would be easy for you). > > If you are agreeable to working on this issue, the first question is can you > reproduce the misaligned Greek characters in the title of PLplot example 3 > (the theta is roughly half a character height too high on my platform as you > can see from the second attachment). Assuming you verify the issue, you may > want to take a different debugging approach than the one I discussed above > such as experimenting directly with text attributes for the qt device driver > until you find a combination that gives good alignment for our example 3 > title. If you can do that, I would be happy to follow up with comprehensive > tests for all our examples to make sure all known character alignment issues > are fixed by your change and there are no alignment regressions. To everyone here who would like to help out with testing: To help understand what I suspect is a qt device driver character alignment issue, I would appreciate some specific testing of example 3 using -dev pngqt to see if there is any platform/set of fonts where you get good character alignment unlike the pngqt result for example 3 that I attached earlier in this thread. Alan |
From: Alban R. <a.r...@im...> - 2009-04-07 13:12:57
|
Alan W. Irwin wrote: > On 2009-04-06 00:53-0700 Alan W. Irwin wrote: > > > > To everyone here who would like to help out with testing: > > To help understand what I suspect is a qt device driver character alignment > issue, I would appreciate some specific testing of example 3 using -dev > pngqt to see if there is any platform/set of fonts where you get good > character alignment unlike the pngqt result for example 3 that I attached > earlier in this thread. > > Alan > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > Hello Alan et al, I've found a curious plplot behaviour having a closer look at example 3: monitoring the font changes, it looks like there are font changes before and after writing the thetas, switching from Times to Helvetica. I don't think this is a problem in the Qt driver parser, as the font change also occurs in wxwidgets. Obviously, Qt doesn't align the different fonts on the same baselines. Is this font switch justified by anything? Cheers, Alban |
From: Alan W. I. <ir...@be...> - 2009-04-07 16:29:30
|
On 2009-04-07 14:11+0100 Alban Rochel wrote: > Hello Alan et al, > > I've found a curious plplot behaviour having a closer look at example 3: > monitoring the font changes, it looks like there are font changes before > and after writing the thetas, switching from Times to Helvetica. I don't > think this is a problem in the Qt driver parser, as the font change also > occurs in wxwidgets. Obviously, Qt doesn't align the different fonts on > the same baselines. > > Is this font switch justified by anything? Note, that PLplot users always have the capability of switch fonts within strings so it is essential to make sure the alignment is not affected by such a switch. To give you some additional background, in this case you are not seeing a result of some FCI command inserted in the example 3 code. Instead, the FCI is inserted automatically by the PLplot core. This is a necessity because we have to support the first-generation plfreetype approach as well for dealing with unicode fonts. Unlike cairo.c and qt.cpp, the plfreetype approach has no method of automatically switching to the best system font to render the unicode glyph required by PLplot. Instead, plfreetype fonts are controlled only by file name. To avoid the situation where the user would have to insert special font-changing FCIs for every non-ascii character in PLplot strings, PLplot does this automatically by switching to the "symbol" font momentarily for each such non-Latin character. (Look for the comment "momentarily switch to symbol font" within plcore.c.) This greatly simplifies the user's life when they are using device drivers which depend on plfreetype. In the cairo and qt cases these automatic FCI's are redundant but should be relatively harmless since the symbol font for both those device drivers is simply defined as sans (or the equivalent generic Helvetica which stands for sans in the qt case) so the glyph finding algorithm just goes ahead and finds the best sans glyph. The result does look a bit peculiar when the string is actually generic serif, but nobody has ever complained about this. Eventually, I think we will probably retire the plfreetype approach altogether and strip out the automatic switch to symbol font at the same time. But we are always going to have deliberate font switches in the middle of strings by PLplot users so qt must always have the capability of dealing with FCI's in the middle of strings without losing alignment whether the FCI is automatically generated or not. 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 __________________________ |
From: Alban R. <a.r...@im...> - 2009-04-07 14:41:35
Attachments:
qt_driver_patch
|
Alan W. Irwin wrote: > On 2009-04-06 00:53-0700 Alan W. Irwin wrote: > > To everyone here who would like to help out with testing: > > To help understand what I suspect is a qt device driver character alignment > issue, I would appreciate some specific testing of example 3 using -dev > pngqt to see if there is any platform/set of fonts where you get good > character alignment unlike the pngqt result for example 3 that I attached > earlier in this thread. > > Alan > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > Alan, Looking in plcore, I realized that plplot switched to the "Symbol" font before plotting a symbol, which is not supported in our driver (not declared as a StyleHint in Qt), and was just ignored, dropping through the "switch" statements to the default, which was helvetica. I've changed this part, so that requesting a "symbol" font just keeps the settings of the previous font. And everything gets aligned properly now in example 3. A patch is attached. Alban |
From: Alan W. I. <ir...@be...> - 2009-04-07 16:57:02
|
On 2009-04-07 15:40+0100 Alban Rochel wrote: > Alan, > > Looking in plcore, I realized that plplot switched to the "Symbol" font > before plotting a symbol, which is not supported in our driver (not > declared as a StyleHint in Qt), and was just ignored, dropping through > the "switch" statements to the default, which was helvetica. I've > changed this part, so that requesting a "symbol" font just keeps the > settings of the previous font. And everything gets aligned properly now > in example 3. > > A patch is attached. If I understand your patch correctly, it works around the alignment problem by ignoring FCI's within strings. But that drops an important PLplot capability (the ability of PLplot users to deliberately change fonts in the middle of a string). Note, also, that currently in the unpatched svn trunk code, we have case 0: case3: case4: default: f.setFamily("Helvetica"); f.setStyleHint(QFont::SansSerif); break; case 4 _is_ the symbol font so that automatically gets translated to the generic Helvetica/sans-serif case just like should happen. I assume from what you have said that currently unpatched svn trunk does the character alignment for the whole string rather than for each individual glyph. If that assumption is correct, then that is the real issue here, and the proper and simple cure is to do the alignment independently for each glyph in the string. Remember, the font can change from one glyph to the next in the string not only because of PLplot FCI's (automatic or deliberate user FCI's) but also because of the font finding done by the underlying Qt code that might also change the font in the middle of a string to get the highest-quality glyph or even to avoid missing glyphs for some fonts. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-04-07 21:13:31
|
On 2009-04-07 09:56-0700 Alan W. Irwin wrote: > On 2009-04-07 15:40+0100 Alban Rochel wrote: > >> Alan, >> >> Looking in plcore, I realized that plplot switched to the "Symbol" font >> before plotting a symbol, which is not supported in our driver (not >> declared as a StyleHint in Qt), and was just ignored, dropping through >> the "switch" statements to the default, which was helvetica. I've >> changed this part, so that requesting a "symbol" font just keeps the >> settings of the previous font. And everything gets aligned properly now >> in example 3. >> >> A patch is attached. > > If I understand your patch correctly, it works around the alignment problem > by ignoring FCI's within strings. But that drops an important PLplot > capability (the ability of PLplot users to deliberately change fonts in the > middle of a string). > > Note, also, that currently in the unpatched svn trunk code, we have > > case 0: case3: case4: default: f.setFamily("Helvetica"); > f.setStyleHint(QFont::SansSerif); > break; > > case 4 _is_ the symbol font so that automatically gets translated to the > generic Helvetica/sans-serif case just like should happen. > > I assume from what you have said that currently unpatched svn trunk does the > character alignment for the whole string rather than for each individual > glyph. If that assumption is correct, then that is the real issue here, and > the proper and simple cure is to do the alignment independently for each > glyph in the string. Remember, the font can change from one glyph to the > next in the string not only because of PLplot FCI's (automatic or deliberate > user FCI's) but also because of the font finding done by the underlying Qt > code that might also change the font in the middle of a string to get the > highest-quality glyph or even to avoid missing glyphs for some fonts. Hi again, Alban: I have done a bit more research on these issues, and now I am not sure any more of what the real issue is. :-( I looked at the model of how cairo.c processes strings since it seems to deal with all issues correctly. Notice there, that ucs4_to_pango_markup_format gives results which are a mixture of glyph codes (UTF8 in this case) and pango markup codes. That mixture of glyphs and markup commands is then further processed natively by libpango/libcairo to actually render the text. So this approach automatically allows changing fonts in the middle of strings. It would be great if we could use a similar approach (to mix glyph codes and markup commands that Qt processes further in native mode) with Qt, but I have not seen anything like that in the Qt documentation. However, I think your present approach (to break up strings into subsets with constant fonts and other markup) should handle the case of changing the font in the middle of strings correctly. Thus, I don't understand why the vertical misalignment is happening for this case for example 3. Just to explore possibilities some more, I applied the following temporary patch which makes the symbol font be serif rather than sans. Index: qt.cpp =================================================================== --- qt.cpp (revision 9780) +++ qt.cpp (working copy) @@ -268,7 +268,8 @@ switch(fontFamily) { case 1: f.setFamily("Times"); f.setStyleHint(QFont::Serif); break; case 2: f.setFamily("Courier"); f.setStyleHint(QFont::TypeWriter); break; - case 0: case3: case4: default: f.setFamily("Helvetica"); f.setStyleHint(QFont::SansSerif); break; + //case 0: case3: case4: default: f.setFamily("Helvetica"); f.setStyleHint(QFont::SansSerif); break; + case 0: case3: case4: default: f.setFamily("Times"); f.setStyleHint(QFont::Serif); break; } if(fontStyle) f.setItalic(true); if(fontWeight) f.setWeight(QFont::Bold); For this case (which is obviously not the general fix we want), the example 3 thetas are aligned correctly! Note that in example 3 the string we are dealing with is "#frPLplot Example 3 - r(#gh)=sin 5#gh". The #fr is an old-fashioned escape sequence to switch to font case 1 e.g., Times/serif, and the #gh is an old-fashioned escape sequence the does three things: (1) switch to case 4 font in PLplot core, (2) asks the device driver to render a unicode Greek theta, and (3) switch back to the original font (case 1 font in this case) in the PLplot core. Why should vertical alignment be affected by whether case 4 is serif (the original font for this particular string) or sans? I hope the additional background I have given you here and in previous posts in this thread will help you to answer that key question. 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 __________________________ |
From: Alban R. <a.r...@im...> - 2009-04-08 14:09:28
Attachments:
qt_driver_patch
|
Alan W. Irwin wrote: > On 2009-04-07 09:56-0700 Alan W. Irwin wrote: > > Hi again, Alban: > > I have done a bit more research on these issues, and now I am not sure any > more of what the real issue is. :-( > > I looked at the model of how cairo.c processes strings since it seems to > deal with all issues correctly. Notice there, that > ucs4_to_pango_markup_format gives results which are a mixture of glyph codes > (UTF8 in this case) and pango markup codes. That mixture of glyphs and > markup commands is then further processed natively by libpango/libcairo to > actually render the text. So this approach automatically allows changing > fonts in the middle of strings. > > It would be great if we could use a similar approach (to mix glyph codes and > markup commands that Qt processes further in native mode) with Qt, but I > have not seen anything like that in the Qt documentation. However, I think > your present approach (to break up strings into subsets with constant fonts > and other markup) should handle the case of changing the font in the middle > of strings correctly. Thus, I don't understand why the vertical > misalignment is happening for this case for example 3. > > Just to explore possibilities some more, I applied the following temporary > patch which makes the symbol font be serif rather than sans. > > Index: qt.cpp > =================================================================== > --- qt.cpp (revision 9780) > +++ qt.cpp (working copy) > @@ -268,7 +268,8 @@ > switch(fontFamily) { > case 1: f.setFamily("Times"); f.setStyleHint(QFont::Serif); break; > case 2: f.setFamily("Courier"); f.setStyleHint(QFont::TypeWriter); break; > - case 0: case3: case4: default: f.setFamily("Helvetica"); f.setStyleHint(QFont::SansSerif); break; > + //case 0: case3: case4: default: f.setFamily("Helvetica"); f.setStyleHint(QFont::SansSerif); break; > + case 0: case3: case4: default: f.setFamily("Times"); f.setStyleHint(QFont::Serif); break; > } > if(fontStyle) f.setItalic(true); > if(fontWeight) f.setWeight(QFont::Bold); > > For this case (which is obviously not the general fix we want), the example > 3 thetas are aligned correctly! > > Note that in example 3 the string we are dealing with is "#frPLplot Example > 3 - r(#gh)=sin 5#gh". The #fr is an old-fashioned escape sequence to switch > to font case 1 e.g., Times/serif, and the #gh is an old-fashioned escape > sequence the does three things: (1) switch to case 4 font in PLplot core, > (2) asks the device driver to render a unicode Greek theta, and (3) switch > back to the original font (case 1 font in this case) in the PLplot core. Why > should vertical alignment be affected by whether case 4 is serif (the > original font for this particular string) or sans? > > I hope the additional background I have given you here and in previous posts > in this thread will help you to answer that key question. > > 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 > __________________________ > 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! For your information, Imperial College closes tonight for Easter and re-opens Wednesday next week. I will be away during this period. Cheers, Alban |
From: Alan W. I. <ir...@be...> - 2009-04-10 19:17:02
|
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 __________________________ |