Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alan W. Irwin <irwin@be...>]

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
__________________________

[Plplot-devel] More on qt Greek glyph misalignment

[Alan W. Irwin <irwin@be...>]

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
__________________________

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alan W. Irwin <irwin@be...>]

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

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alban Rochel <a.rochel@im...>]

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
> Plplot-devel@...
> 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

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alan W. Irwin <irwin@be...>]

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
__________________________

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alban Rochel <a.rochel@im...>]

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
> Plplot-devel@...
> 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

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alan W. Irwin <irwin@be...>]

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
__________________________

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alan W. Irwin <irwin@be...>]

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
__________________________

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alban Rochel <a.rochel@im...>]

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

Re: [Plplot-devel] More on qt Greek glyph misalignment

[Alan W. Irwin <irwin@be...>]

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
__________________________