Re: Bidi proposal, implementation

["Chahine M. Hamila" <mch at chaham dot com>]

Behdad Esfahbod wrote:

> On Sat, 18 Aug 2001, Chahine M. Hamila wrote:
> 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...

Well, not really. I have worked long enough on console drivers to know it's
not. Actually, bidi will be more or less managed as long as some conditions
are met, like when a sequence of the same directional characters are not cut
by screen limits. This is for example statistically often the case with
applications which cut texts on a word level, but not always true. I've given
a brief description on why bidi can NOT be correctly implemented on a
terminal. At best, you will have an approximate result.
Note that at some time, I even thought I would use fribidi to deal with
terminals and had to dismiss it for the reasons I mentionned.

> You are talking about a pure rtl system, not bidirectional systems,

Actually, I am talking about both. Converting a pure l2r system in a pure r2l
system is trivial, much more trivial than converting a l2r system into a
bidirectional one, and today's systems are essentially l2r (putting aside
systems that can NOT be bidirectional like terminals displays). Hence the
idea of converting l2r systems in r2l systems. They might not be perfect, but
they would be a giant leap in direction of Arabization for a cheap
effort. Later, when things advance and more and more high level applications
with advanced word-based capabilities will be bidirectional, we could base
stuff on them. Again, our problem is that unicode made it possible to use the
good old English texts from monodirectional software with bidi algorithms,
but it didn't cross their mind that it could be interesting to have the same
about texts containing at least one word of Arabic used on monodirectional
software.

> but almost all of us prefer ltr based systems,

true, all geeks use ltr based systems. Arab kids and my Arab grand-ma don't
(and I am pretty sure the same goes with an Iranian kid who haven't studied
English yet). They simply don't read mail and are unable to start their games
without assistance because they don't read a single letter of Latin. Those
who can afford investing a few months of salary in the latest Pentium would
buy a completely Arabized version of Win98 (a 486 wouldn't be enough coz
Win98 refuses to install on the old ones). So what are we left with? Refuse
access to unixes and geek tools forever to Arab kids, and ask them to wait
til an acceptable number of acceptable quality software acquires bidi
capabilities in order to read their mails without investing in a
Pentium/Arabic-Win98 machine. Or, make every l2r system optionally r2l in a
raw.

> 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...,

True. The thing is, we've all managed with l2r well until today, and we will
probably manage for some time. I am not saying it should be
THE solution. What I am saying is that it is a solution, and it is a pity we
don't make this cheaply/easily acquired one compatible with the more complete
but hardest (impossible in some cases) to implement unicode bidi one, just
like it is in English.

> that of course are more
> used than rtl ones, even for me, you, roozbeh, ...

Yes, and I will probably keep using an l2r system. If you ask me, I could
live without ever writing a word of Arabic, so I'm not really the target for
this work;)
No seriously, I'll tell you about the approach: one should be able to switch
between an r2l or l2r view, just like one does on a bidi capable word
processor. In Akka for example, a control code is supposed to allow
that. Which means, one can still type non arabized commands for example, and
yet, when getting under VI, switch the console in r2l and start typing in
Arabic/Persian/Syriac/whatever...
Yes, it would be better if VI had unicode bidi capabilities, but we won't
wait til every software does (which won't happen in a near future
anyway). Why not be able to edit a text with VI or any other system *today*,
and be able to use the same text tomorrow with a unicodebidied VI tomorrow
just like it's the case for any English text?

Salam.