On 2010-10-05 13:02+0100 Steve Schwartz wrote:

> [...]Gucharmap shows both
> the symbols and alternatives, and the xcairo driver finds them, so I
> guess they reside somehow on my system but not accessed by my version of
> qt (4.5.3).

I used to encounter this same difficulty (Qt was not as good at
finding system fonts as xcairo and gucharmap).  I speculate that older
versions of Qt used their own library for finding system fonts and not
the standard fontconfig library that is used by xcairo and gucharmap
or else Qt used fontconfig in a poorly configured way.  However, for
Qt-4.6.3 (the version that comes with Debian testing) I have not
encountered this issue.  For example, the Hershey numbers below are
all rendered fine with example 7 and -dev qtwidget.

> Hershey numbers    plplot5.9.7 unicode      change to this
> 46, 546                  0x03d2                  0x03a5     Upsilon
> 534                      0x03d1                  0x03b8     theta
> 98, 684, 2184            0x03f5                  0x03b5     epsilon
> 686, 2186                0x03d5                  0x03c6     phi variant

As you can see from Section 2.28 of our release announcement, later
versions of Qt seem to solve a number of issues we see for earlier
versions of Qt so the fix for this font-finding issue appears to be
just one more fix in the series of Qt improvements that also doesn't
seem to have introduced any regressions (at least up to 4.6.3).  So
TrollTech/Nokia seem to have a pretty good track record for
constantly improving Qt4.

The Qt download site at http://qt.nokia.com/downloads/ gives you
access to the latest Qt version (currently 4.7.0) in binary form.  If
that version works well for you (i.e., solves the above issue without
introducing any regressions), then you might want to recommend it to
your QSAS users that don't have access to Qt-4.6.3 or above from their
distribution.  Alternatively, you could temporarily deploy the above
workaround until essentially all distros have updated to 4.6.3 or
above.

Finally, these issues remind me again that plpoin and plsym access
unicode glyphs in an indirect and extremely limited way. Therefore, I
have decided it is long past time we introduced a new function
plglyph(n, x, y, ucs4) which allowed plotting glyphs corresponding to
the ucs4 index for those drivers which are unicode aware.  Such a
function would allow users full and direct access to the extremely
wide variety of generic sans and serif glyphs that are available on
their system for unicode-aware device drivers like qt (with Qt-4.6.3
or later) or cairo.  I will try implementing a first cut at plglyph
later today.

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
__________________________

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to