Re: Bidi proposal, implementation

[Behdad Esfahbod <behdad at bamdad dot org>]

On Sat, 18 Aug 2001, Chahine M. Hamila wrote:
> After all the resistance to change I received, I came to the conclusion
> that no proposal could work if it requires any change to what has been
> done before.
> This complicates our work a bit since we have to keep in mind both the
> fact that the loss would be great not to be able to use existing
> monodirectional programs, and at the same time we have to manage with
> legacy unicode algorithm.
> The idea has then been to introduce the change as an extension to the
> existing unicode alg implementations. I will change the text of the
> proposal accordingly.
> I will just say a few words about it now. Limiting yourself to the
> existing unicode algorithm means you have to write pure English text
> (not one single word of Arabic) or use software with bidirectional
> capabilities (impossible in some cases). If you want to write Arabic on
> a non-bidirectional capable program (i.e. most existing software today),
> you will *have to* use the extensions mentioned when reading/editing it
> from a bidirectional capable program. By using them as described in the
> proposal, you will actually be able to write any kind of text.

I do not agree. Bidi terminals try to solve the problem, have a look
at bidi-xterm, non-bidirectional capable programs like cat, pine,
lynx, ... work there almost well, the same will be true when we
add bidi capabilities to console, it already has a standard, it needs
to be revised, but it exists...

> The implementation is based on the fribidi library.
> Two functions have been added:
> - fribidi_enable_bidi_ext
> which enables the use of the extensions,
> - fribidi_assumed_orientation,
> which changes the assumed direction when the extensions are enabled.
> By default, for an Arabic user, we strongly recommend that the bidi
> extensions would be enabled and the assumed orientation would be right
> to left. It should be possible for a user to enable disable these
> parameters manually.
> This will be the only way to make it possible to read correctly Arabic
> stuff written with VI, emacs (etc...) which don't have bidirectional
> capabilities. When doing this, Arabization could be summarized to
> inverting the X coordinates on low level display drivers and translation
> of documentation.

You are talking about a pure rtl system, not bidirectional systems,
but almost all of us prefer ltr based systems, you need to read your
english mails, ..., and if you invert the X coordinate, then you will
have all of the problems with ltr scripts..., that of course are more
used than rtl ones, even for me, you, roozbeh, ...

> All the existing fribidi API has been preserved and it should be
> possible to simple change the library with the patched one and continue
> using the usual fribidi based soft without any modification (Pango for
> example).
> A new idiosyncracy (in a unicode encoding) will be introduced to force
> the assumed display (in order to avoid me some research, people with
> unicode knowledge have a suggestion on which code to use?).
>
> Unfortunately, as you can notice with Akka, things are very slow since
> I am very busy. If someone wants to continue developping the proposed
> extension to the fribidi library, please go ahead, I'm all available for
> directions (this would be a nice work for a newbie as the fribidi
> library code is fairly easy to master).

please just use the latest code from cvs:

  http://sourceforge.net/cvs/?group_id=2722

> Salam,
> Chahine

Yours,
-- 
Behdad
27 Mordad 1380, 2001 Aug 18

[Finger for Geek Code]