Add BiDi infrastructure

Shachar Shemesh wine-devel at sun.consumer.org.il
Tue Aug 20 02:47:53 CDT 2002


Alexandre Julliard wrote:

>Shachar Shemesh <wine-devel at sun.consumer.org.il> writes:
>
>  
>
>>   3. Things are further complicated by the fact that it has no out of
>>      bounds way of specifying what the base direction is (and, MS being
>>      MS, this means that a base direction of LTR is chosen, and not
>>      according to the Unicode algorithm).
>>    
>>
>
>Isn't that what the GCPCLASS_PREBOUNDLTR etc. flags are about? Or is
>this something different?
>  
>
You would think so, wouldn't you? I mean, that would be the logical 
thing to do. When reading the manual, it is obvious that this is what's 
its there for. It does seem a bit strange that you would have to 
allocate an array the size of the string just for this single byte 
specifying direction, but still....

While on the subject, using the unicode standard of upercase means 
Hebrew and lowercase means English, you'd expect the following string:
english HEBREW
when used with clases saying all characters are Hebrew, to be reordered to:
WERBEH hsilgne
What you WOULDNT expect, is to get
eWERBEH hsilgn

The sad truth of the matter is that a LOT more investigation will be 
required until we realize what lpClass is doing, and I don't think any 
commercial or other needed that function badly enough to go through this 
investigation. The end result is that I don't believe we will EVER 
really have to do that research.

>>Is fribidi going to support all the functionality we are likely to
>>need? Yes, I believe it will. That is why I tried to stress the amount
>>of shortcutting this library is going to get us. Implementing the
>>various unicode algorithms is a pain, and one to be avoided. If, at
>>some stage in the future, it turns out that some programs really do
>>need classes from GetCharacterPlacement, well, we'll have this
>>discussion again.
>>    
>>
>
>That's not acceptable. It's perfectly OK to say that we won't
>implement some things until we find something that needs them, but
>it's not OK to pick a design that will prevent us from implementing
>them once they are needed (and they *will* become needed someday).
>  
>
I may have came across wrong. I am not suggesting we stick to libfribidi 
forever, whatever it can do is fine, and what it can't won't be done. To 
emphasize this point, you will notice that my patch does not export any 
of libfribidi's functions. In retrospect, I think I'll rename the .c 
file to "bidi" - will be more apropriate.

I am saying that it is covering all of our current needs, and thus we 
should go for it as it saves us somewhere between a month of work and 
half a year (calendaric time, estimates based on assumption that I'm the 
only one working on it). If at some future time we come to the 
conclusion that libfribidi is not enough, we can either add the required 
functionality to it, integrate it into Wine or replace it altogether. I 
am hoping that, by that time, interest in wine will be high enough for 
more people to be involved.

In any case, I tried to create the interfaces so that "fribidi" is not a 
dominant part of them.

            Shachar





More information about the wine-devel mailing list