I have just completed (for revison 9777) an extensive comparison between qt device driver results (for the downloadable Qt-4.5 which is essential for getting good svgqt results) and cairo device driver results.
The short story is the results from the qt device driver are looking good, and I urge all developers/testers here to give it a try to make sure there are no showstopper issues on some platform or for some monitor resolution that Alban and I have not tested. In fact, there are only three issues I am now aware of for the qt device driver. (1) Dashed lines implemented within the device driver were not working correctly (see below) prior to revision 9776. I have bypassed (probably permanently) that issue by letting the PLplot core handle dashed lines (just like most other drivers do) for revision 9776. (2) text clipping issues (see below). (3) stream issues revealed by example 14 which we have discussed before. I doubt Alban will want to investigate (1) futher since the PLplot core alternative for drawing dashed lines works well. He has told me off-list he plans to deal with issues (2) and (3) this week. Now for the longer story concerning my detailed test results. Sorry this is so long, but the excuse for it is there are a lot of different results from my testing that need to be reported for the record and also anybody who is deeply interested in how well the qt device performs. I have made a number of recent small but important revisions to generate the improved final results for my tests. Revision 9771 improves the logical separation between qt devices whose dimensions are measured in physical units (points or mm) (epsqt, pdfqt, and svgqt), devices whose size is measured in pixels, but whose corresponding dimension in physical units are presumably known if X is configured so that "xdpyinfo |grep resolution" gives the actual correct resolution of the device (qtwidget), and "raster" devices (bmpqt, jpgqt, pngqt, ppmqt, tiffqt) whose size is measured in pixels. Revision 9773 deploys (for Qt4.5 and above) the essential setviewbox attribute for SVG files generated with -dev svgqt. Revision 9776 lets the PLplot core handle dashed lines since the driver results for this capability have a number of issues (see below). Revision 9777 changes the new logically separated parameter for raster devices (called DEFAULT_DPI) from 80 back to the old DPI value (72, see below). Here is how I made my comprehensive tests. I locally adjusted plplot-test.sh to use the -geometry 720x540 option for all qt-related devices so the qt results would agree in size with the default size for the cairo device driver results. To generate the various comparisons (in the installed examples tree) I ran rm -f *.epsqt *.pscairo *.pngqt *.pngcairo *.svgqt *.svgcairo make -j4 \ x01c01.epsqt x01c.pscairo \ x01c01.pngqt x01c01.pngcairo \ x01c01.svgqt x01c01.svgcairo to generate 6 x 130 pages (!) of plots to look at. With so many pages it is essential to automate the visual comparison as much as possible, e.g. for FILE in *.epsqt; do echo $FILE; gv -orientation=landscape \ -geometry +0+0 $FILE; done for FILE in *.pscairo; do echo $FILE; gv -orientation=landscape \ -geometry +0+0 $FILE; done I used similar commands to visually compare superimposed pngqt and pngcairo results (using the ImageMagick "display" application) and superimposed svgqt and svgcairo results (again using the ImageMagick "display" application). As we know for -dev svg results the display application does not have reliable text offsets, but that turns out not to be an issue for the two (!) other ways text is handled by -dev svgcairo and -dev svgqt. Also, compared to konqueror and firefox (other alternative viewers of -dev svgqt and -dev svcairo results on Debian Lenny which also have reliable text offsets for -dev svg), "display" has much more reliable access to the unicode fonts for -dev svgqt. -dev svgcairo results include embedded "fonts" (i.e., the svg commands to draw the glyphs) so access to fonts is not an issue for those results. I also ran examples/python/test_circle.py in the installed examples for -dev epsqt and -dev pscairo and compared superimposed results. The actual visual comparisons (e.g., between corresponding pscairo and epsqt results) were done by "blinking" back and forth between exactly superimposed images (which is the best/most efficient way to visually compare plots). Here are my notes concerning those visual comparisons. * Dashed line issues before revision 9776. Examples 1, 9 (most pages), 19 (3rd page longitude lines but not latitude lines), and probably others: Dashed lines generated by qt don't have the same spacing and sometimes not the regularity of spacing as for cairo. This is probably an issue with the way that QtPLDriver::setDashed interfaces between PLplot's representation of dashed lines and Qt4's representation. I bypassed this issue (revision 9776) by letting the PLplot core library handle dashed lines rather than letting the qt device driver handle them via QtPLDriver::setDashed. This actually is a good solution so Alban probably wont want to investigate further what is wrong with QtPLDriver::setDashed. * For plots with multiple sub-pages per page (e.g., example 1), the raster qt results (e.g., pngqt) had rather small text relative to the non-raster qt results for -dpi 80 and -geometry 720x540. (Note -dpi is ignored for all qt devices other than the raster devices.) I get better results for example 1 using -dpi 72 for a wide range of geometry values. I did some further raster device tests leaving the Qt4 value of dpi constant while varying the PLplot value. That resulted in character sizes dropping dramatically with increasing dpi. For the reverse test (constant dpi for PLplot while allowing the Qt4 value to vary, character sizes increased dramatically with dpi. The two combined effects mean that character size is independent of dpi value for dpi=72 and below. Above that value it slowly and sometimes erratically drops, then increased rapidly again for quite high dpi values. For dpi below 72 the size of the dashes for dashed lines becomes too small so -dpi 72 seems to be a good compromise value. This value of 72 is consistent with what Alban used for his previous tests for quite different monitor resolution. We should therefore stick with a DEFAULT_DPI value of 72 for the raster devices unless tests by others reveal size isses for characters or the lengths of the dashes in dashed lines for monitor resolutions other than those (80 for me, 120 for Alban) that have been tested so far. * Example 2 (and all other examples as well) shows cairo number glyphs are wider relative to their height and offset slightly higher. Their height was slightly larger as well. But gucharmap shows these are real differences between the default sans font you get for qt (Arial) and cairo (DejaVu Sans). So it appears the Qt and Pango/Cairo libraries are passing the intended exact size, proportion, and offset (as displayed by gucharmap) of the selected font through to the qt and cairo devices. IOW, qt and cairo libraries and device drivers are all acting as expected, and there appear to be no qt device driver adjustments required for basic glyphs. This good result also appears to extend to other basic glyphs such as upper and lower case Latin characters and for all mathematical symbols (other than Greek letters, see comments below). * test_circle.py. gucharmap shows that Arial does not include glyphs for the LARGE CIRCLE (unicode 0x25ef) and LIGHT DIAGONAL CROSS (unicode 0x2573) glyphs used for this example. So QT4.5 made some font substitution for "Helvetica" (i.e., a generic sans font) that it felt was right. I suspect that was DejaVu Sans (the sans font favored by cairo on my system), but I am not sure. Anyhow, the Qt offsets seem fine confirming the good offset results for example 2. However, the rendered shapes are really strange compared to the good qt shapes you get for basic glyphs. The LARGE CIRCLE is too big at all sizes and is not round (noticeably squashed on the left). See the attached screenshots. The LIGHT DIAGONAL CROSS is too big. gucharmap shows for both these unicode glyphs there is no system font that renders with a larger size than DejaVu Sans or with a squashed circle. I also looked specifically at the svgqt versus svgcairo results. In those cases the font rendering for -dev svgqt is done by the "display" application rather than Qt4 itself. The squashed effect disappears for that case, but the svgqt size for both LARGE CIRCLE and LIGHT DIAGONAL CROSS continues to be too large consistent with the results for the other qt devices for these two glyphs. I am positive the squashed effect is due to some QT-4.x glyph rendering issue, and the size issue for these two glyphs is probably an additional QT4 issue. The Cairo results for this example are fine (as I mentioned in a previous post). * Example 8 shows slightly better qt results (smoothed edges on the surface plots) than cairo results. * Example 9 and 21 show text clipping issues for qt. The contour labels for the first page of example 9 and the "X" symbols for the random points of the first page of example 21 are not clipped properly at the viewport boundaries. Alban plans to deal with this issue this week. * Examples 3, 7 and 23 show that Greek letters have a substantial vertical shift (~40 per cent of the height) for qt. This is not an intended offset according to gucharmap. I looked closely at example 23 for the svgqt case, and the Greek letter theta in the title is deliberately offset vertically. If I edit that SVG file and use the same y value as the rest of the latin characters in the Title string, then it brings the theta back into line with the rest. Qt4 seems to be convinced that these vertical offsets must be used for the Greek characters, and I strongly suspect that there is some Qt4 screwup with how the vertical position of the Greek characters is determined (at least for the Greek fonts installed on my Debian Lenny platform). Since this issue may be platform dependent, further testing of this particular problem on other platforms is requested. Example 23 shows the remaining large numbers of mathematical symbols displayed by that example have good allignment for qt. * Example 24. For the QT results, the CTL languages had substantial but consistent (for the same language/device) vertical offsets of the "Peace" word. But the offsets for various languages vary inconsistently from, e.g, epsqt to pngqt. This issue is similar to the Greek letter issue noted above. (although I don't think there is qt device specific variation in how bad the effect is for that case). I am virtually positive these results indicate a rendering bug in Qt4.5 and have nothing to do with deficiencies in the qt device driver. The Cairo glyphs for the various languages and fonts all have good vertical alignment for this example. * Example 31. 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.In sum, my extensive testing of the qt device driver results against the corresponding cairo results for epsqt, pngqt, and svgqt (with spot checks
for qtwidget) shows good qt rendering in the vast majority of cases and even one instance where Qt4 does a better rendering job than libpango/libcairo. There are some scattered instances where Qt4 rendering is not as good as the libpango/libcairo rendering (from the scientific plotting perspective the worst of these is the displaced Greek letters). However, these rendering problems appear to be outside our control. Thus, these tests indicate the qt device driver now has mature unicode text and plot rendering with no further rendering changes anticipated at the qt device driver level other than dealing with the text clipping issue mentioned above. Now that the qt device driver is giving me good rendering results (for the downloadable Qt-4.5) with the exception of the relatively few issues mentioned above, I urge everybody here to test it on the platforms that are accessible to them to make sure it is as mature as I think it is. :-) 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 __________________________
cairotest.ps
Description: /test_circle.py -dev pscairo results
qttest.ps
Description: /test_circle.py -dev epsqt results
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
