From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Tue Apr 23 2002 - 10:28:03 EDT
> Hebrew is very easy. It only has 4 final forms. I'm
> not sure if we support Hebrew vowel points because
> that is harder. Arabic is a lot more comples but
> nowhere near as complex as Indian scripts and Thai
> is probably somewhere in between.
Just for those interested, the bidi build can handle up to 5
overstriking characters together (I believe that is more than
Pango!). At the moment it works for Hebrew vowels, accents,
daggesh, etc. The only thing that is needed to expand this to other
languages is to type in the character data into the tables in
ut_OverstrikingChars class. We do glyph shaping both for Hebrew
and Arabic, although the Arabic side needs someone to test it
properly. We can do shaping for any other script that has
initial/medial/final/isolate glyph forms and has separate Unicode
codepoints for the separate shapes, providing someone enters the
character data into the ut_ContextGlyph class. We also do 2-
character ligatures for Arabic, again we can do 2-character
ligatures for any other language, just the data needs to be typed
into ut_ContextGlyph shape (the data for little nicities like ff and fi
ligatures is already there, but it is commented out, because it only
works on Windows due to font problems).
The existing shaping engine is very basic and in medium/long run
we will need a _suitable_ replacement. But at the moment, that is
not very high on my list of priorities, because (1) there is no user
pressure to do this, respectively, there are no developers streaming
to deal with this (2) with the existing shaping engine, we already
have the basic shaping API in place, so once we find a suitable
engine (and I am looking), it should be fairly straight forward
making the switch. (3) To be able to do the shaping and
combination characters properly and consistently, we have to be
able to use OpenType fonts properly on all our platforms.
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.
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 preference would be
to migrate to FreeType now, and the use the planned FreeType
text-layout library when it appears, even if that means having to
substantially chip into its development. The reason I would
progress in this direction is that this would exactly match of what
the current layout engine is capable of at its limits, which is
producing line-based layout. Pango is a much higher level formatter
than we can currently make use of, and so at present it would be,
IMO, an overkill. To use Pango properly, we would have to through
out everything in the layout engine starting at block, and below.
That time will surely, come, but it is not here yet, and further, I am
not sure that Pango is sufficienly mature at this point to justify this
level of rewrite -- I would hate to end up worth of than we are.
> I've been trying to get Thai and Indian developers
> interested for ages but the always start off
> enthusiastic then get disheartened and leave ):
Same story for Arabic. But the bottom line is that in Open Source
communites get what they are prepared to contribute to, and I am
not going feel bad about not supporting Arabic properly if no Arabic
folk want to chip in. We do what we can.
Tomas
This archive was generated by hypermail 2.1.4 : Tue Apr 23 2002 - 10:33:40 EDT