From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Tue Apr 23 2002 - 11:39:11 EDT
--- Tomas Frydrych <tomas@frydrych.uklinux.net>
wrote: >
> > 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,
Does it actually render all 5 characters into the one
character cell or does it need to map them to a
precomposed character? For Vietnamese we usually need
the former and usually don't have fonts to do the
latter. For Thai and Indic I don't think Unicode
even attempts to have all the precomposed forms.
> accents,
> daggesh, etc. The only thing that is needed to
Cool! Does it support the Arabic vowels?
> 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
I'll be able to test it somewhat when I can get my
hands on a computer but my Arabic skills are pretty
basic.
> that has
> initial/medial/final/isolate glyph forms and has
> separate Unicode
Maybe Syriac. Greek has a final form for Sigma but I
read somewhere that this is usually handled specially.
Indian scripts don't care about position but have
extremely complex ligature requirements.
> codepoints for the separate shapes, providing
The problem is that we don't just need the codepoints,
we need fonts that support the codepoints. Vietnamese
has the codepoints but most Vietnamese fonts don't.
> 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).
I think these font problems are going to become a more
prominent problem the further we get.
> 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
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.
> 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.
This means Xft on X too, right?
> 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.
> 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
We might try getting some of them to chip into our
development too (:
> 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
Can we do Devanagari support without it? MSWord can
do very good Devanagari right now.
Again this is a good place for more details.
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?
> 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.
Again please tell us what Pango is missing for us
specifically.
> > I've been trying to get Thai and Indian developers
> > interested for ages but they 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.
Maybe I should put some time into learning Arabic and
making an Arabic AbiWord homepage (:
Andrew Dunbar.
> Tomas
=====
http://linguaphile.sourceforge.net http://www.abisource.com
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
This archive was generated by hypermail 2.1.4 : Tue Apr 23 2002 - 11:40:28 EDT