On 2006-06-05 12:32+0100 Andrew Ross wrote:
> You tests with a repeated running of the C / C++ examples at least
> confirm that the font problem is some C / C++ issue and not simply
> that fonconfig is doing a round robin or some such to deal with ties
> in the font selection.
> It is hard to see how this could happen since we are using the same
> libraries and code in each case. Pango / fonconfig should have no way
> of knowing whether we are using the C or C++ bindings. My only thought
> is that it could be a linking issue. It is still hard to see what
> difference this could make.
> Anyway, pango allows you to specify a list of fonts rather than just
> one font so I've updated psttf.c to put a few specific font names in
> (Arial, FreeSans and Bitstream-Vera-Sans for sans etc) in, as well as
> the generic names. Hopefully, in case of a tie, you will have these
> specified names selected over any other installed fonts. I am loathed
> to remove the generic names, since it allows a lot of extra freedom to
> find the "right" font for unusual glyphs.
> Alan, does this help produce more consistent results on your Ubuntu
> box? If so, then I guess we need some mechanism to alter these
> "preferred" fonts at configure time.
Your psttf.c change removed all differences between the C (test1.ps, see
attached) and C++ (test2.ps) examples. However, there remain some differences
between the Java example (test.ps) and the others. I attach the results of
"diff test.ps test1.ps >diff.out" for you to look at. To me, it appears
test1.ps (the C example result) has defined two extra possible characters
involving the ae_AlArabiya-Regular font, but in fact those are never used so
it makes no difference in the C/C++ results except they are a little bigger
than necessary. There is one substantive difference though at the end with
< gsave -332.728 0.000 rmoveto
> gsave -300.444 0.000 rmoveto
This difference results in a noticable horizontal shift in the Arabic word
for Peace (but no glyph differences) when you view the two results with gv.
I double-checked there is no difference in positions between
java/x24.java and c/x23c.c.
Do you get such horizontal shifts between your java and C/C++ examples?
To attempt to replicate the Ubuntu behaviour on a non-Ubuntu system, I tried
installing the ttf-arabeyes package (the source of many of the extra fonts
on the Ubuntu system) on my Debian stable system. Without your psttf.c
change, I still got identical C/C++ results with all the added Arabic fonts.
I am using LASi-1.0.5 for all my tests (and so are you), and now it appears
extra Arabic fonts don't matter on Debian stable. Thus, I am beginning to
suspect the original effect I found on Ubuntu (the C/C++ difference) and the
continuing strange differences between Java and C/C++ results on Ubuntu are
caused by some subtle bug either in psttf or else the versions of libpango
and libfontconfig that are available on Ubuntu.
To sort out the possibilities, we need test results on additional platforms.
For example, can you confirm any C/C++ differences on the Ubuntu (hoary?)
platform that is available to you without your psttf change? What are
the prospects of upgrading that system to either Ubuntu breezy or dapper?
I appeal also for example 24 psttfc tests for all other users here. I am
particularly interested in Debian testing and Debian unstable since Ubuntu
breezy corresponds roughly to something in between those two versions
BTW, Andrew, since your recent change to psttf was only partially successful
at removing C/C++/Java differences on Ubuntu, and adding a large number of
Arabic fonts to Debian stable made no difference even without your change,
that means the working hypothesis we were using (font score ties were
causing the C/C++/Java inconcistencies in results) is not correct. Thus, you
may want to revert your psttf change until we can determine the real source
of the problem.
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 Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project