Re: Request for comments on Square Arabic

["Chahine M. Hamila" <HALCON11 at terra dot es>]

Salaam,

we could as well keep on writing on papyrus as our ancestors did;) Just kidding:)
More seriously, you are both right and wrong in that sense Yasser. We definitely have to present the user with
software that will allow him to do shaped and quality calligraphic software when needed. On the other hand,
this is not always the case, and sometimes, it impedes more than helps, like in the case of terminals where the
fact acronyms and abbreviations are (will be) common, decreases readability of shaped Arabic. So reverting to
"Square Arabic", "Unified Arabic" or whatever it has been/is being/will be called, eliminates problems in some
circumstances, and solve them in others. Eliminate problems in that sense that simple editors or emailers to
quote only these do not have particular needs as to the style of scripture as long as they are *perfectly and
confortably readable*. Solve them in that sense that it increases even readability in some circumstances as
mentionned. Mind you, whether you read your mail using "traditional Arabic", "tahoma" or I don't know which
other font doesn't really matter, does it? So why not "Square Arabic"? In fact, why not *especially* "Square
Arabic" which makes a hell lot of a sense on the technological side?
Note that in terms of Arabic, there are mainly two or three stages in order to internationalize existing
software.
- add shaping
- add RTL support (this is by far the simplest in term of implementation and the less algorithmic consuming in
terms of efficiency)

- add bidi when desired and IF possible

If you eliminate the shaping stage when it's not necessarily needed (without any compromise on the user
confort's side), you simply divide the algorithmic complexity by O(N) at the most basic level, display, which
is a *gigantic* leap (not just from an "ivory tower" academic point of view, but from a very practical
consideration in terms of efficiency).
What would remain if leaving shaping aside (considering monodirectional software)? RTL, which is a most trivial
arithmetic operation on the X coordinate, thus rendering Arabic software as simple as English software to
develop and use. As an effect in fact, this would have the consequence of speeding a lot conversion of existing
software. MS only "solved" the problem in that sense that you only have a set of uniform high level components
of which you can't get out. But if you are going to base your work on lower level libraries than win's gui
ones, or alternative ones, the problem is definitely not solved. Comparatively, you can add this to GTK for
example thus making adapting GTK software trivial, but you won't impact the least on QT, Xlib, console stuff,
proprietary stuff and so on and so on.
So the easier the Arabization work is on the developer side (obviously keeping the no-trade rule on the user
side of course), the more will be done in a shorter time span, the more the user will have choice and tools,
etc, etc... And the more efficient it is, the more diversely it will be practically possible to develop
software, etc, etc... This is especially true when one considers how encouraging the enthusiam of all those
developers we're seeing rushing at developing free arabic software...

We are only of course talking about the general case of most basic software, we are not talking about high
level word processors and other software that have any kind of typographic requirements.

So, summary:
- Pros:
    - no change, Arabic remains carved in marble rock and stoned like a dead mummy for those who are touchy
about this
    - Great technological gain in quantity and efficiency, without trade on the user side
- Cons:
    - none that I can think of...

Best regards,
Chahine