From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Wed Apr 24 2002 - 07:07:30 EDT
> Andrew Dunbar:
> Does it actually render all 5 characters into the one
> character cell or does it need to map them to a
> precomposed character?
It lays the 5 characters over each other.
> Cool! Does it support the Arabic vowels?
No, I have no knowledge of Arabic, the only stuff I implemented is
the consonant shaping and support for 2-char ligatures. I would love
to do more, but it is beyond my abilities.
> Maybe Syriac.
Unfortunately, Syriac is defined purely semantically in Unicode, the
shaping is delegated to font renderers, which is one reason why we
really need OpenType support.
> Greek has a final form for Sigma but I
> read somewhere that this is usually handled specially.
The Greek data is in the tables, but I have no idea what a Greek
user expects. (I got into trouble because of automatic shaping for
Hebrew; the normal Israeli user does not expect that, so I had to
add a checkbox into preferences and it is off by default).
> Indian scripts don't care about position but have
> extremely complex ligature requirements.
We could improve the ligature support, but that may not be the
best the way to go. We will need to use a 3-rd party renderer for all
of this stuff sooner or later.
> I think these font problems are going to become a more
> prominent problem the further we get.
I think you are right. That's one reason why I am so keen to
migrate to FreeType, for that should at least make things easier.
> We need to push for Hebrew, Arabic, Thai and Indian
> language users - or at least testers! Especially the
> first two since they work pretty good on the current
> AbiWord - we should really make a special effort to
> announce AbiWord 1.0 on Hebrew and Arabic Linux and/or
> free software sites if they exist.
I have been trying. There are quite a few Hebrew testers involved
now, and it is working fairly satisfactory. Folk from the
Arabeyes.org project expressed interest recently, and hopefully we
will get some contributions from them.
There is though another problem. The Hebrew-speaking folk are
interested in Hebrew, which means their interest stops largely at
the level of Fribidi functionality. The Arabeyes folk are interested in
Arabic, planning to produce shaping engine for Arabic that could be
used alongside fribidi. For me the scope is too limited. I would be
happy to plug in 3rd party Arabic shaping engine, but ultimately I
want more than that. In long run, Pango (or something like it) is the
answer, it certainly has got the vision, but even in the medium run,
I would like to be able to do more, to support any language that
has line-based layout and for which the shaping can be done via
the Unicode codepoints.
> > Consequently, I want us to migrate to FreeType ASAP.
> > This will give us a level playing field on all platforms, and
> > rid us of huge problems on Unix and the serious difficulties caused
> > by inconsistent behaviour of the myriad of Windows.
>
> This means Xft on X too, right?
No, FreeType is independent of any system font mechanism; it
parses the font files and gives you the glyphs as bitmaps.
> > As far as Pango is concerned, apart from the
> > portability problems, from what I have seen, its API would make it very
> > difficult to integrate with the existing layout engine. My
>
> Can you give us some concrete, technical examples?
> Please CC the GTK I18N list too so we can get comments
> straight from the Pango guys.
No, I cannot :). But as far as I understand, Pango is a fairly high
level formatter, it does something like our fl_BlockLayout class,
and we would have to replace the blockLayout with it
_to_get_most_out_of_it_. This basically means throwing our entire
existing layout engine out and start again. It could well be the best
thing to do right now, but I am not fully convinced.
> I'm under the impression that using Pango will make
> exotic languages "just work" in places such as
> dialogs and widgets too. We might handle the rendering
> nicely on screen but can we handle it in say the
> spellchecker window or in window title bars?
I am not sure that is the case; what we can do with the widgets
depends on what the widgets can do, and that varies from OS to
OS. But this is a real issue we will have to address as well.
> Again please tell us what Pango is missing for us specifically.
I am not saying Pango is missing anything, I am merely not sure
that the folk who advocate using Pango have strayed past the
Pango home page. It is about time that someone undertook as
serious feasibility study of using Pango.
> Surely we would use Pango only for rendering the
> straight "runs" of text. All formatting including
> tabs we would do ourselves.
If that is all we want to use Pango for, then we have to migrate to
freetype first, because we will be left to do the screen drawing
using glyph indices, and we do not want to do this in platform
specific code, because that would mean having the whole shaping
system in platform specific code, since the indices are system-
dependent. Also, no-one should assume that this is trivial, to quote
from the Pango docs: "While complete access to the layout
capabilities of Pango is provided using the detailed interfaces for
itemization and shaping, using that functionality directly involves
writing a fairly large amount of code."
> Surely if pango can give us a shape
> to print on the screen it can give us one to print on
> a printer - but I don't know printers alas...
Pango, if used in the way you envisage, only gives us a glyph
indices, but even if it gave us actual shapes, this would be of no
use for generating PostScrip. In the Unix World the fact we can
draw it on screen does not mean we can print it via PostScript,
because we could well be using non-PostScript fonts on the
screen. Again, I am not saying there is a problem, merely that this
issue has to be looked into, for being able to support a myriad of
languages on screen is not enough in itself.
Just for the record, I am _not_ objecting to us using Pango, neither
for low-level shaping, nor for high level layout. I am objecting to
deciding to use Pango without thinking seriously through what
would be involved, what it would bring us, and *WHO WILL DO THE
CODING*. The bidi experience taught me that not that many
people will do the coding when it comes to more "exotic"
internationalization. Even in its most reduced form, the migration to
Pango would require serious commitment from the entire
development team, without it we should stop even talking about it
right now. As for me, I am entirely convinced that we will have to
migrate to using a 3rd party layout engine sooner or later, and if
Pango is the best choice, let's use it.
Tomas
This archive was generated by hypermail 2.1.4 : Wed Apr 24 2002 - 07:12:43 EDT