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

[Shachar Shemesh]

Not looking at the source yet, I may be talking utter bullshit here.

What I think will be the proper thing to do is to change two locations:
1. When classifying the characters, do the surrogate unification, lookup 
the combined code point, and then mark both parts of the surrogate as 
the same type.
2. When reordering, if the level is odd (right to left), and the char is 
a surrogate, don't change the order of the pair.

As far as I can see, these are the only changes required in order to 
support UTF-16. They can be relatively trivially extended to support UTF-8.

If anyone who has actually had a look at the code has anything to 
correct me, please do.

            Shachar

Behdad Esfahbod wrote:

>On Sat, 24 Aug 2002, Dov Grobgeld wrote:
>
>  
>
>>On Sat, Aug 24, 2002 at 04:40:39AM +0430, Behdad Esfahbod wrote:
>>    
>>
>>>Windows API, ans so WINE's uses UTF-16.  And WINE people reject 
>>>to use a 32bit bidi library and convert back and forth all the 
>>>time, so they need UTF-16 support internally.
>>>      
>>>
>>I just looked at the fribidi source code and the only place which makes use of
>>the encoding of the string is (the static) fribidi_analyse_string().  It would
>>be quite easy to add an extra "encoding" parameter so that it would be easy to
>>support both UTF-16 and UCS4 (I refuse to say UTF-32, as there is no boundry
>>checks in fribidi. ;-). We could then enter the encoding as a property
>>of the FribidiEnv. The runtime overhead should be very small to get a library
>>that supports both encoding types.
>>    
>>
>
>You are a little wrong Dov, we are assuming 
>sizeof (FriBidiChar) == 4, at least the compiler is assuming this 
>when compiling, so its quite easy in compile time, but not so 
>easy in run-time.  I prefer not to support it in run-time.
>
>  
>
>>Regards,
>>Dov
>>    
>>
>
>  
>