[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fribidi and joining
- To: developer at arabeyes dot org
- Subject: Re: Fribidi and joining
- From: Nadim Shaikli <shaikli at yahoo dot com>
- Date: Wed, 21 Aug 2002 18:01:51 -0700 (PDT)
On Tue, 20 Aug 2002 03:24:38 +0430 (IRST),
"Roozbeh Pournader" <roozbeh sharif edu> wrote:
> Well, #arabeyes is becoming a little productive for me. Today Nadim was
> wondering when we'll have fribidi+joining, and I couldn't have a guess
> since Behdad (maintainer and main coder of FriBidi) had not recieved much
> feedback on his new API design, and that new API will happen before (or at
> the same time as) the introduction of joining.
> For those with a lot of free time at hand, following are the references.
> I'll try to post a more explanatory thing a few days later (please remind
> me if I forgot).
> Unicode Bidirectional Algorithm, that FriBidi implements:
> Unicode description of Arabic:
> (the joining section is at the end of Section 8.2). And finally Behdad's
> email on the new FriBidi interface, which he needs real feedback for:
For what its worth, some definitions,
+ Joining is the same as shaping; defined as the morphing of the
Arabic/Persian character to fit its location within the word
(e.g. MEEM looks different depending on its location within the
word -- initial, medial, final, stand-alone).
+ Bidi is defined as Bi-directionality -- having the ability to see
Arabic/Persian rendered correctly (from right-to-left) while seeing
Latin (english/french/etc) from left-to-right.
To put more beef to this discussion, fribidi after much wrangling and
convincing is slated to add shaping/joining support to their library but
what has happened is that Behdad/Roozbeh have found instances in which
its not quite that simple to do (how common are those cases btw ?).
In other words, its not simple enough to just run Bidi and then shape
characters (or vice versa) due to some ambiguity to what needs to happen
in certain scenarios (at least that's been my understanding). Its been
noted that it might look as though fribidi will have to do some initial
Bidi'ing, then shape then complete the Bidi.
What are those scenarios and could we see a example or two of 'em ?
(this question was posed, but it seems as though unicode bidi gurus
were stumped and that its rather complicated and thus the need and
requirement, as noted above, to re-read all the specs and get __very__
familiar with the requirements).
A couple of things to note,
+ Behdad/Roozbeh are working on putting a document together describing
the problem and giving more details with some possible solutions/hacks
(at least that's what the unicode people had asked 'em to do). I would
love to see the problem statement even before a solution is found (out
of shear curiosity I guess, plus it will certainly force me to go reread
the specs again :-)
+ Microsoft has solved this problem somehow in their own proprietary way
(typical), but had Pango, QT and/or IBM's ICU ? Behdad/Roozbeh have
you guys run your test-cases on those libraries ? Are their authors
aware of these issues (Pango used fribidi, don't know if that's still
+ While working on a solution (don't know how much of an overhaul will
be required of the spec), can reversibility be sneaked in ?
In terms of getting feedback on the new Fribidi API, I think the fribidi
list would certainly have a more informed, immediate and critical view of
life since the internals of fribidi are a mystery to many here, I'd guess.
If memory serves, none of the 'fribidi-discuss' subscribers has issues
with Behdad's initial API which leads me to believe that its most likely
OK given whatever problem you guys have recently discovered is taken care
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes