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
__________________________
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
