Re: fribidi & arabic shaping

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

Nadim Shaikli a *crit :

>
> I believe both shaping and reordering act strictly on a visual basis (if
> they didn't we'd be in DEEP trouble :-)

Not exactly:)
See what follows:)

> In short what happens today,
>
>  1. string_A = application produces string (screen-line buffer)
>  2. out_fri = fribidi(string_A, other stuff :-)
>  3. out_vis = someone else graps out_fri and does shaping substitution
>  4. out_vis goes to display engine (and font calls, scaling, etc)
>
> It would be ideal to put step 2/3 above into one - that's all.  Its definitely
> not as complicated as you might think -- its about 60 lines of code.

In 2, you are acting on a character encoding. In 3, you are converting a logical
encoding, even in the most simple application mentionned above, to visual glyph
codes. There is some information that is shared between steps 3 and 4, which is
the glyph encoding within the fonts used. IOW, integrating step 3 in step 2 would
mean you have to feed step 2 with that information. Which in turn means you will
have to change the fribidi lib reordering call to be able to play with glyph
codes, implying changing its interface and/or all applications that use it if you
want shaping support in them anyway.
In addition to this, you might need some precious information at the logical level
in the reordered string that could be useful for the interface's interaction for
example, or unordered string searches...
So the problem is not as much a matter of how complicated it would be as much as
it would be a matter of having the choice between:
- breaking compatibility with all existing fribidi based apps, since they would
need to use the new interface,
- write some more lines in every application for arabic support anyway
Both cases make the point of this addition useless, because both cases would
amount pretty much to adding pango, or would even be more difficult...

Salaam,
Chahine