[Fribidi-discuss] Some thoughts about BiDi Quirks Handling

[Omer Zak]

On Sat, 21 Sep 2002, Shachar Shemesh wrote:

> Just wanted to state the obvious - I would find such a feature useful as 
> well.

[... snipped ...]

> Omer Zak wrote:
> 
> >Possible approaches:
> >--------------------
> >1. Implement few "quirks" flags in FriBidi (the FriBidiEnv structure has
> >   room for those flags).  When set, those flags would cause FriBidi to
> >   behave like one of the incompatible BiDi algorithms.
> >
> Most convinient to users, no doubt, but isn't it a bit out of fribidi's 
> charter?

What is FriBidi's charter anyway?
Even if my suggestions are outside of FriBidi's original charter
(presumably to provide an efficient and LGPLed implementation of the
Unicode BiDi algorithm), I understand that the software package will be
even more useful if it can be configured to handle incompatible BiDi
algorithms - at least under the control of compile-time options (so as not
to burden users who don't need the quirks with code which implements the
quirks).

> >2. Add to FriBidi special code, which would flag the characters in a
> >   string, which would be reordered differently in the different BiDi
> >   algorithms.  The wordprocessor would then display those characters in a
> >   different way, and let the user determine whether they were reordered
> >   the way he intended to or not.
> >
> I think the best way to handle that one (and perhaps solve the "1" 
> problem without breaking charter) is to adopt the new proposed 
> interface. With the new interface, the char types are calculated by one 
> function, and then this array is passed on to a second function for 
> reordering. I even believe (have not checked yet) that we can implement 
> the MS quirks by simply overriding some character's types BiDi types to 
> another, existing, Unicode BiDi types, and then using the same algorithm.

Great, the discussion is in terms of "this is a good idea, how can we
implement it?".  If reclassifying characters is indeed the answer, then
let clients of FriBidi provide their own character classifications as a
runtime configurable parameter to FriBidi (as another field FriBidiEnv).

IMPORTANT:  is there anywhere information about the incompatibilities of
the various BiDi implementations, and is there anyone who can perform the
analysis of the quirks and design how to accommodate them within the
framework of FriBidi?

> >3. The import filters, used by the Free wordprocessors to import files
> >   created by a given version of Microsoft wordprocessor, would insert
> >   explicit BiDi overrides at those places where the BiDi algorithms would
> >   produce different visual orderings of characters.
> >
> But then, what about Wine? What about OpenOffice? What about Mozilla 
> (actually, I think they are using their own algorithm already)? What 
> about QT KWord? What about Pango?

Wine needs to be compatible with Microsoft.
OpenOffice, Mozilla, QT KWord and Pango are Free Software (or at least
Open Source), we can expect them to use the Unicode algorithm everywhere.
There is not enough base of users of previous versions with whom one needs
to retain compatibility (at least I hope this is the situation).

                                             --- Omer
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html