Add BiDi infrastructure

[Shachar Shemesh]

Alexandre Julliard wrote:

>Shachar Shemesh <wine-devel at sun.consumer.org.il> writes:
>
>  
>
>>If the general public here votes to remove the ac related code, I'll
>>go along with it (no question about it making my code simpler, albeit
>>marginally).
>>    
>>
>
>I suggest you write the real code first, and let us worry about the
>configure stuff later. There is no point in adding configure
>dependencies for non-existing code, and once the code is done we can
>have a better idea of what dependencies you actually need.
>
I have the creeping suspicion you don't realize just how much of a 
shortcut using fribidi is. All of the stuff we have there already that 
says "exteremely preliminary" is going to be replaced with approximately 
four to five lines of code.

Then again, since you will probably only have time to look at it on 
Monday, and since "the rest of the code" is hopefully going to be ready 
by then, let's just postpone the discussion a bit :-)

>As mentioned already, I think including the fribidi algorithms
>directly in the code is a better approach, but the only way to really
>say which is the right way is to get something working.
>  
>
I talked to Behdad (one of the libfribidi maintainers) about this some 
time ago. Basically, the Unicode BiDirectional code is fully Unicode 3.2 
complient, and no changes are expected there (assuming Unicode don't 
change the algorithm itself again, like they did between 3.0 and 3.2, 
2.1 and 3.0, 2.0 and 2.1, and that's just the versions I have on record. 
Everything before 2.0 is a total blank to me).

The thing that is not yet complete, and which I have neither the 
resources nor the knowledge to handle, is the glyphing support (read - 
Arabic). Since it is interesting to me to have the working (but not 
interesting enough to try and dust off my extremely rusty Arabic), and 
since no Arabic speaking programmer vulonteered to step up to the task 
on either this list, the Israel Linux mailing list, or the Ivrix mailing 
list (where libfribidi was originally brewed), and since the only Arabic 
representative who did contact me disappeared with no trace after two 
emails, if we don't use an external library for this, we won't have any 
support for this at all.

At the moment, I think it is particularily counter-useful to have 
mandatory BiDi support in Wine, as this means (among mere applying the 
BiDi algorithm) translating each string printed to UTF-32 and back 
(unless we can say for sure that no BiDi is going to be required - 
havn't found a really good algorithm for that yet, but I'm working on 
it). Not having the proper library on your machine is a pretty good way 
of indicating that BiDi is not interesting to you (and is, more or less, 
the way MS tackled the exact same dillema).

The only thing that can cause me to change my mind about this is if 
porting libfribidi to UTF-16 will, indeed, be as easy as Behdad 
suggested. Personally, I have my doubts where sarrogates are used in 
right-to-left context (hi-lo order may get reveresed, and the characters 
hopelessly mangled). If, however, we can invest minimal effort and get a 
UTF-16 fork of libfribidi, I will see no sense in non-Wine distribution 
of this fork. Please understand, however, that this is a fork, and it 
will need to remain synchronized with the main branch.

Personally, I think my time would be better spent trying to get the edit 
control to work BiDi (a problem not solved in mozilla, for example), 
hunt down why DrawText doesn't always use the correct charset, add the 
charset selection to the "ChooseFont" dialog, make sure that switching 
keyboards send out the WM_KEYCHANGE message, or any other of the endless 
list of tasks still waiting to be done before we can truely say that 
Wine supports BiDi. There is still a long long way to go, and this is 
really just the begining.

                    Shachar