[Fribidi-discuss] Re: BiDi WINE status and fribidi

[Omer Zak]

On Fri, 23 Aug 2002, Shachar Shemesh wrote:

> Quoting your relevant web page:
>
>
>   Is this a fork?
>
> Unfortunately, yes - for the time being. It is my hope that Dov Grobgeld
> will incorporate the changes made in this version into the next
> mainstream version of his FriBidi package.

Sorry, but this information is obsolete and I didn't bother to update the
Web page.  At the time version 0.1.14 was in use, and I wasn't successful
in contacting Dob Grobgeld due to technical reasons.

The version being used now is 0.11.0, and it incorporates my bug fixes
from the time as well as various enhancements, which should make it easier
for you to use (including some support for work under MS-Windows).

>
> >There are some Unicode code points, which cannot be represented in 16
> >bits, but I believe that WINE can live without supporting those code
> >points (which would otherwise require surrogates in UTF-16).
> >
> That, I'm afraid, is where you are wrong. These codepages are crucial
> for far east support, and Wine in general cannot live without them. What
> I am willing to do is add surrogate support to fribidi, however. This
> shouldn't pose TOO much of a problem, but it means #ifdefs in the code.

General issue:
We use flags (in FriBidiEnv) to tailor the FriBidi algorithm to various
situations.  In general, they should be usable in lieu of #ifdef's.
However, some people may need a lightweight version of FriBidi, omitting
code which supports certain flag settings.
Therefore, it may be necessary to accompany each flag with #ifdef around
code which implements it.

> >About pointB, I don't have an opinion at the moment.But if it requires
> >a different behavior of the FriBidi algorithm, maybe this can be
> >accommodated by adding another flag to FriBidiEnv and have the algorithm
> >do whatever you want if the flag is set.
> >
> It requires an override. The way Windows do it is:
> A. Badly. I couldn't get it to work at all at first, and then work in a
> most bizar way.
> B. Providing an array the size of the string specifying overrides (i.e.
> - the third character is a Hebrew character, no matter what the Unicode
> tables say). As you need such an array anyways, and as even the Windows
> function fills this array in after reordering with the missing data, you
> can use the user supplied array for your own processing. It is this
> requirement that should be relatively easy to support (but will require
> interface changes)-:

Does this mean that MS-Windows does not follow exactly the Unicode
standard when handling the special directional override character codes?

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