[no subject]

dia 0.88.1 had perfect string-level rendering (because we delegated to
the Postscript engine, which typically had close scrutinity from
typography experts), a glyph-level rendering which varied from perfect
(English-speaking world) to unusable (the user who wanted to use more
than one non-English language in a single diagram) with various
intermediate levels (latin1 was okay, latin2 often required warts like
ogonkify, Japanese had a good boost Akira TAGOH, but forget about Hindic
scripts, etc.).
The diagram level rendering sucked, as it was basically a lottery
whether you text would be properly aligned with respect to graphic
elements, leave unwanted gaps, or overflow.

When we went to gtk2.0, we needed to improve the glyph level (because
GNOME cares for I18N/L10N/W6R), and sure the diagram-level was itching.

The temporary compromise we did was to sacrifice the string level to
improve the two others. Yes, that's at the expense of typography and
Postscript types, but at least the product starts to be barely usable
for non-Western users.

The real solution would be for either Pango or a complementary
library to be able to execute the hinting stuff at the rendering stage,
and predictably, accurately match what the rasteriser will choose to do, in a 
dependable way (short of mandating that every raster device has a
resolution of exactly 9600dpi, including paper and screen, I don't see
how to do this, but there are a lot of smarter people than I).
With that, we'll be able to take the Pango-or-complementary library's
word for what the width of a given text string is, and assume the
Postscript rasteriser will agree and output a string of "exactly" the same
width, modulo what the human eye is actually able to see.

(Of course, this assumes that said library has access to the same font
outlines and hints as the rasteriser, which is relatively easy if you
decide the fonts are to be downloaded, but requires a certain amount of
faith if you really insist on sending Postscript files over a 1200 bit/s
RS-232 line -- or have a million embedded EPS files in a LaTeX document,
been there, done that).

This "magic library" I just described is clearly out of dia's
responsibility. There are several attempts to do that, PangoPS/PangoPDF
is one, GNOME-Print is another (but I really don't think you like G-P's
text output). I'd think anything GPL-compatible and legally kosher will
do the job if it doesn't bring a boatload of new dependencies. If it's
done to become a standard library (an official Pango component would fit
the role wonderfully), this would be perfect.

 -- Cyrille 

--