On 2009-03-13 11:47-0000 Alban Rochel wrote: > Alan, > > Alan W. Irwin wrote: >> I applied the subsequent patch you sent to remove all special SVG text >> offsets. (Revision 9730.) The resulting svgqt text placement is not >> correct on konqueror so there may indeed be a bug in the Qt library in the >> way they produce (as opposed to view) SVG files with text. >> >> I have included the following screenshots of the second page of example 2 >> so that you know exactly what I am looking at. > > I've compared what I get to what you produced, and the results are... > interesting :0 > >> (1) -dev pngcairo results as viewed by the ImageMagick "display" >> application >> (which unlike SVG's gives reliable results for text positioning within >> PNG's). The glyphs appear to be well centred in their boxes (just like >> all other cairo results including svgcairo as displayed by konqueror). > > Same thing for me > >> (2) konqueror result for -dev svg. If you stare really hard at it, you >> will >> notice that result is off centre to the left compared to the first >> screenshot, but the effect is just barely noticeable so we didn't bother to >> correct it for -dev svg. > > I have to open the file in Inkscape to get the same output as you. In > konqueror, see the attachment (svg_in_konqueror.png). Offset, color, font, > nothing is right!
My konqueror version is ir...@raven> konqueror --version Qt: 3.3.8b KDE: 3.5.10 Konqueror: 3.5.9 One of the nice things about -dev svg is we are completely in control of that device driver since there are no external library dependencies. For -dev svg results we have checked out text positioning on a whole bunch of different platforms/applications, and got consistently good results except for (a) anything having to do with librsvg, and (b) old software versions (e.g., Scribus versus Scribus_ng). Steve Schwartz provided many of these results so you will want to check with him. It's possible your konqueoror version is older than mine. On the other hand it may be newer, and there may be some text positioning bug (and text color bug) introduced in the new version. I also get good -dev svg results for iceweasel (a.k.a. firefox). It's version here is Mozilla Iceweasel 2.0.0.14, Copyright (c) 1998 - 2008 mozilla.org Do your firefox results look good for -dev svg? If so, I would stick with firefox (or inkscape) for testing of -dev svgqt. > [...]Depending on what software I use, I get different (wrong) results, but > still > different from yours! (svgqt_in_konqueror.png svgqt_in_inkscape.png). Firefox > gives the same thing as Inkscape (they may have the same rendering engine, I > haven't checked). Well, my bad results with konqueror and your bad inkscape results (both for application versions that produce good -dev svg results) for -dev svgqt indicate Qt issues with producing svg results. That lead me to a further test which indicates bad trouble with Qt and SVG. I just tried to validate -dev svgqt results at http://validator.w3.org/ via the file upload method. There are three errors. The first is that it cannot automatically detect that it is svg. So I specified svg 1.1. After that override it detected 2 svg validation errors (for qttest02.svg, the second page of example 2 generated by -dev svgqt). If you do decide to file a bug report with qt, these validation issues should be addressed with the highest priority since there is no excuse for QT to produce SVG results tht are not compliant with the standard. Meanwhile, I don't think we should be concerned about other errors in the svgqt results until the validation issues are fixed. I have disabled svgqt (revision 9736) to discourage users from further testing of this device because of these known issues that require non-PLplot (Qt) work to fix. Note, both -dev svgcairo and -dev svg produce results that are cleanly validated by that site. > >> (4) -dev pngqt result as displayed by ImageMagick "display". The position >> is >> too high, but the shift is small so you may not want to fix that. >> >> The size of the characters is consistent with those from -dev svqqt, i.e., >> they should be expanded by ~20 per cent or so to be consistent with the >> size >> of the characters from -dev svg > > On my system, it's better, but the font is wrong (sans-serif): pngqt.png Actually, I think the font choice is fine. Comparing your pngqt result with mine, I think they use identical san-serif fonts (but different sizes) for the second page of example 2. Visual inspection of the numbers block displayed by gucharmap with different system fonts seems to give a good match with Arial which is a sans-serif font. A similar gucharmap experiment with the pngcairo results for the same page indicates DejaVu Sans was used in that case. So both the pango and qt glyph choosing systems are coming up with sans fonts in both cases, and I think that is the best we can expect unless and until we configure fontconfig to use the same criteria as Qt for choosing sans glyphs or vice versa. So I think the only pngqt issues here are the following two issues: (1) The slightly high offset (look at the 5's and 8's) demonstrated in both my pngqt results and yours. (2) The ~20 per cent difference in glyph sizes between my results and yours. (More on that issue below.) > >> (5) -dev qtwidget results showing the excessively small size of the glyphs >> for that case. I mentioned this issue before, but did not realize at the >> time the size problem was only this severe for -dev qtwidget. The centering >> looks good now for these small glyphs, but my guess is it will appear >> slightly too high (like -dev pngqt) once the glyphs are adjusted to be the >> correct size (like those of the first two screenshots). > > Again, mine's better yet not perfect (qtwidget.png) The two issues here are the following: (1) The x offset of your qtwidget result needs adjustment; the numbers are shifted slightly too far to the right so you need a slight negative x adjustment. Also, I see no evidence that a negative y adjustmen is needed (unlike for pngqt). In fact, a slight positive y adjustment might be required instead. My glyphs are so small I cannot see whether my qtwidget alignment issues are identical with yours. But because our pngqt results agreed in this respect, my guess is our qtwidget results will also (once the size of the glyphs are the same). Anyhow, the principal curiosity is why are the offsets different for qtwidget and pngqt? (2) The large (factor of two) difference in glyph size between our qtwidget results. This second issue is quite puzzling for both -dev pngqt and -dev qtwidget. Why should my glyph size change so dramatically between the two devices while yours do not? I am now wondering if you have a misconfigured X so the glyph sizes you get on your system are not trustworthy. Here is what I get for my X setup and monitor: ir...@raven> xdpyinfo | egrep '(dimensions|resolution)' dimensions: 1024x768 pixels (327x243 millimeters) resolution: 80x80 dots per inch That 80 dots per inch corresponds to 3.15 pixels/mm which is close enough to the 1024/327 = 3.13 and 768/243 = 3.16 pixel/mm values I calculate from the above "dimensions" data. I have informed X of the actual display size, 327x243 millimeters, by using the DisplaySize 327 243 in the monitor section of /etc/X11/xorg.conf file. You may have to do the same to get reliable results from xdpyinfo. If I use the -geometry option to specify a particular size in pixels for the display for interactive PLplot devices, e.g., c/x02c -dev xcairo -geometry 800x600 c/x02c -dev xwin -geometry 800x600 c/x02c -dev gcw -geometry 800x600 then that displayed area should actually measure 254x191 mm from the above "resolution" data from xdpyinfo. I actually measure that size to be 253x187mm using my trusty meter stick which is quite close to the prediction. Could you please do a similar series of comparisons for your platform making sure, first of all, that xdpyinfo is giving reasonable results? (If not, then you probably need to inform X of the actual size of your monitor with the DisplaySize option.) Assuming xdpyinfo gives reasonable results for the x and y resolution, do you also get a good prediction of the size of -dev xcairo, xwin, and gcw results using the "resolution" numbers reported by xdpyinfo? The above -geometry results highlight an additional low-priority issue for qt which is we should get that device driver to recognize the PLplot -geometry option so the user has complete control of the pixel size of his results for all qt-related device results. 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 __________________________ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
