> 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

Reply via email to