[Fribidi-discuss] BiDi WINE status and fribidi

[Shachar Shemesh]

Behdad Esfahbod wrote:

>So finally  here is, the lord of all fribidi branches ;) (effects 
>of reading "Just for Fun", by Linus Torvalds, these days).
>
>It seems that don't replying is a real good way of getting good 
>comments and making other people think on fribidi :).
>
>More below:
>
>On Thu, 22 Aug 2002, Shachar Shemesh wrote:
>[snip]
>  
>
>>The main limitations we feel prevent Wine from using fribidi are:
>>A. fribidi's use of UTF-32, vs. UTF-16 by Windows.
>>    
>>
>
>I have decided to implement UTF-16 myself, no hard work, but of 
>course, its a compile time option, like --enable-utf16, and I try 
>to rename the output library to fribidi16 or something like that, 
>to be able to have both 16 and 32 bit versions installed on a 
>machine.
>  
>
The second part (having both installed simultaniously) is an extremely 
important one.

>>B. Lack of support for out of bounds overriding of character types (the 
>>lpClass parameter of the GCP_RESULTS struct of GetCharacterPlacement. If 
>>anyone is interested in the full details - 
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_4l84.asp)
>>    
>>
>
>If I understand you correctly, you need to be able to state that 
>for example, the bidi type for character 'A' should be RTL, 
>insteal of LTR.
>
No, that's not it.

If the string "car in hebrew is said CAR" would normally get 
"LLLNLLNLLLLLLNLLNLLLLNRRR", I want a user to be able to override, say, 
the first word, saying "RRRdddddddddddddddddddddd" (where "d" means 
"don't care"), resulting in fribidi treating the sentance as 
"RRRNLLNLLLLLLNLLNLLLLNRRR". Notice that the character "a" appears in 
both the first "car", and is being treated as "R", and in "said", and is 
treated as "L" (because it was not overriden).

The interface must also allow the user to get back the final 
classification (regardless of whether he overrided it or not).

One last thing is that the user must be able to provide classification 
to the character right before and right after the string (I have only 
seen any reference to it in the 3.0 standard, but have not read the 3.2 
standard yet. In 3.0 this affects, for example, W2).

>  There are two solutions:
>
>	1. In the next generation interface of fribidi, there is 
>a call that does bidi on given bidi types.  So you can get the 
>bidi types of string from fribidi, override ones you want, and 
>ask it to apply bidi with the given types.
>
That would do it. Rember, I am very skeptic about the chances of anyone 
actually using this feature, and so there is no need to change the 
design (for example - un-RLE the string) just because of this 
requirement. A seperate function should exist that does that, but that 
function has to be neither memory nor CPU efficient, as it is not in the 
main path of execution.

>
>	2. I'm thinking of a global overriding mechanism
>(ofcourse through the fribidienv in the next generations), the 
>idea is having a simple hash table of overrided character types.  
>Its easy to implement.
>  
>
Like I tried to explain - that won't do.

>  
>
>>Unless we create two distinct implementations of libfribidi, I fear that 
>>the best approach for dealing with A is to create a WINE only fork of 
>>fribidi.
>>    
>>
>
>You can simply patch fribidi for your use, and still do not fork 
>it, like the way Owen handles in pango, he has a (huge) patch, 
>that he should update to apply on later versions of fribidi.  Its 
>a little difficult, but is possible. (BTW, fribidi is more more 
>stable now, and it makes future updates easy).
>  
>
If we create a seperate utf-16 fribidi, that will not be necessary.

>  
>
>>B is just something to consider if you indeed want to revise 
>>the fribidi interface 
>>(http://sourceforge.net/mailarchive/forum.php?thread_id=790237&forum_id=3189).
>>    
>>
>
>Some points:
>
>	* I'm really busy for about 4 weeks.  It should be two 
>long for you to wait, so please try implementing something that 
>works, and then we will revise it together when I'm back (yes, I 
>will be in a trip to India for TUG'2002).
>
I will start working on UTF-16 support (once that's in, UTF-8 shouldn't 
be much of a problem, making conversions of any kind unnecessary. I'm 
begining to think maybe packaging fribidi16 seperately is not such a 
good idea after all, but that's up to the packgers). When you come back, 
we'll see where I got to, and you can decide whether my code is worthy 
of merging, or would you rather start from scratch yourself ;-)

>	* Another question is that should I implement B before 
>1.0 or not?  I think I do it, as it's easy to do, and then 
>changing the API for 1.0 is not hard.
>
If it's easy, fine. Don't fuss too much over it, however, as even 
Alexander accepts that this is not a high priority issue. He merely 
states that he will not create dependancy on a library that will NEVER 
solve all of our problems.

                        Shachar