[Fribidi-discuss] Some thoughts about BiDi Quirks Handling

[Tzafrir Cohen]

On Sat, 21 Sep 2002, Shachar Shemesh wrote:

> Just wanted to state the obvious - I would find such a feature useful as
> well.
>
> A few comments:
>
> 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? MS, for various inexplicable reasons, is using totally
> incompatible algorithm. I know that, when I suggested I use their
> original one under WINE, there was an outrage of "don't do that, use the
> proper one and we'll get better apps behaviour". I don't know about that
> one. If it's the one taken, however, I'll gladly use it.
>
> >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.
>
> >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?

OTOH: with the other options: someone needs to insert explicit bidi
overrides. Otherwise the text will look incorrect once copied to any other
program that is not aware of its quirk origin.

>
> >
> >Of the possible approaches, I favor the most the "quirks" flags approach.
> >When importing a document, the user has anyway to specify which
> >wordprocessor created it.It is not a big deal to specify also the
> >corresponding BiDi algorithm version.
> >
> >In the internal representation of documents used by Free wordprocessors,
> >an extra field to specify the BiDi algorithm needs to be added. But if
> >the wordprocessor was designed in a reasonable way, it should not be
> >difficult to add a paragraph-scope attribute to specify the BiDi algorithm
> >to be applied to that paragraph. (Note: paragraph scope is needed to
> >handle the case of an user, who wants to merge together documents created
> >by different wordprocessors, which used different BiDi algorithms.)

But why should abiword care about the history of the paragraph? Why should
some text behave differently if it came from a different origin? What
happenes if you copy a text from a "normal" paragraph to a "quirk"
paragraph?

I like the simplicity of abiword's file format.

-- 
Tzafrir Cohen
mailto:tzafrir at technion.ac.il
http://www.technion.ac.il/~tzafrir