Re: [Plplot-devel] qt text positioning

2009-03-16 Thread Alban Rochel
Hi everyone,

Alan W. Irwin wrote:
 On 2009-03-13 19:27- Andrew Ross wrote:
 
 That explanation makes sense.  Thanks!  In fact, KDE-4.2 has a much better
 reputation than KDE-4.1 so these color/text position rendering issues for
 -dev svg results (as well as other SVG results) may already be resolved by
 KDE-4.2.

That explains it, indeed, I'm still under Kde 4.1. Good news.

 In any case, I now feel we shouldn't worry too much about svgqt until the
 fundamental validation issues get straightened out for the SVG files
 produced by Qt4 so I now have disabled svgqt by default.
 
 The remaining big concern for me is still the size issues for all the other
 qt-related devices.
 
 * Would you be willing to go through the same xdpyinfo and GUI measuring
 exercises (with an actual meter stick) I asked Alban to do to make sure we
 all have dimensions and resolutions configured right on our various Linux
 systems, X configurations, and monitors?

I get the following:

dimensions:1440x900 pixels (304x190 millimeters)
resolution:120x120 dots per inch

Your resolution is 80x80 dpi, which should explain the discrepancy. I 
believed the sizes were computed relatively to the device resolution, 
but I must have omitted something at some point. I'll have a look at it.

 * For -dev pngqt do you get the ~20 per cent smaller glyphs I do or the
 normal-sized glyphs like Alban does?
 
 * For -dev qtwidget do you get the half-size glyphs I do or the normal-sized
 glyphs like Alban does?
 
 (For the last two questions please refer back to the screenshots we both
 recently sent to the list.)
 
 Thanks in advance for your help with these qt glyph size questions.  It will
 be a big help to know what the situation is for each of the Linux platforms
 you have access to.
 
 Alan
 __
 Alan W. Irwin

And thanks to all for the relevant analysis of the SVG and memory issues.

Alban

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


Re: [Plplot-devel] qt text positioning

2009-03-13 Thread Alan W. Irwin
On 2009-03-13 11:47- 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 

Re: [Plplot-devel] qt text positioning

2009-03-13 Thread Andrew Ross
On Fri, Mar 13, 2009 at 12:09:07PM -0700, Alan Irwin wrote:
 On 2009-03-13 11:47- 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
 

Alan, I can answer this on Alban's part based on earlier emails. Kubuntu
8.10 uses KDE 4. 

Qt: 4.4.3
KDE: 4.1.4 (KDE 4.1.4)
Konqueror: 4.1.4 (KDE 4.1.4)

This version is definitely a work in progress - not all apps have been
ported to KDE4 yet, so it is certainly possible that bugs have been
introduced. 

Andrew

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


Re: [Plplot-devel] qt text positioning

2009-03-13 Thread Alan W. Irwin
On 2009-03-13 19:27- Andrew Ross wrote:

 On Fri, Mar 13, 2009 at 12:09:07PM -0700, Alan Irwin wrote:
 On 2009-03-13 11:47- 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


 Alan, I can answer this on Alban's part based on earlier emails. Kubuntu
 8.10 uses KDE 4.

 Qt: 4.4.3
 KDE: 4.1.4 (KDE 4.1.4)
 Konqueror: 4.1.4 (KDE 4.1.4)

 This version is definitely a work in progress - not all apps have been
 ported to KDE4 yet, so it is certainly possible that bugs have been
 introduced.

That explanation makes sense.  Thanks!  In fact, KDE-4.2 has a much better
reputation than KDE-4.1 so these color/text position rendering issues for
-dev svg results (as well as other SVG results) may already be resolved by
KDE-4.2.

In any case, I now feel we shouldn't worry too much about svgqt until the
fundamental validation issues get straightened out for the SVG files
produced by Qt4 so I now have disabled svgqt by default.

The remaining big concern for me is still the size issues for all the other
qt-related devices.

* Would you be willing to go through the same xdpyinfo and GUI measuring
exercises (with an actual meter stick) I asked Alban to do to make sure we
all have dimensions and resolutions configured right on our various Linux
systems, X configurations, and monitors?

* For -dev pngqt do you get the ~20 per cent smaller glyphs I do or the
normal-sized glyphs like Alban does?

* For -dev qtwidget do you get the half-size glyphs I do or the normal-sized
glyphs like Alban does?

(For the last two questions please refer back to the screenshots we both
recently sent to the list.)

Thanks in advance for your help with these qt glyph size questions.  It will
be a big help to know what the situation is for each of the Linux platforms
you have access to.

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