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

[Shachar Shemesh]

Omer Zak wrote:

>On Thu, 22 Aug 2002, Shachar Shemesh wrote:
>
>  
>
>>The main limitations we feel prevent Wine from using fribidi are:
>>A. fribidi's use of UTF-32, vs. UTF-16 by Windows.
>>    
>>
>
>I don't think that recompilation with special compile-time flags
>would constitute forking.
>I had the same problem when porting FriBidi to GEOS (for use in the Nokia
>9110 Communicator).  The problem was solved by forking a single header
>file and typedef'ing datatypes appropriately.
>
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.

>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.

>
>About point B, 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)-:

                Shachar