Alexandre Julliard wrote:
Shachar Shemesh wine-devel@sun.consumer.org.il writes:
No actual patch, yet, as I still have a few heap corruptions in certain cases. Attached, however, is the preliminary "Wine with external libfribidi". Do your worst, come back with an opinion. This is not, yet, cleaned up, but the interface is a pretty good representation of what the final version is going to be.
What I don't see is how you are going to implement all of the GetCharacterPlacement features, like the various override flags, the lpClass array, etc.
The only overrides in "GetCharacterPlacement" are the lpClass parameter. The few weeks of silence from me were spent trying to investigate every aspect of GetCharacterPlacement. The results are, roughly:
1. This function is impossible. It has overlapping arguments, docs are extremely unclear as to what arguments you can avoid supplying, and what arguments are mandatory. 2. The function is supposed to let you do all reordering once, and then repeat the actual printing as many times as necessary. In practice, I find it hard to believe that this is a high priority issue for anyone. 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).
In short, I find it hard to believe that ANYONE would really use that function at all. The lpClass were particularily annoying, as they obviously did SOMETHING, but defenitely not what you would expect. Why is that relevant? Read a little further.
Is fribidi going to support all of that the way we need it?
Is fribidi going to support all the GetCharacterPlacement functionality? No, classes are not going to be supported by it. Everything else should not pose a problem.
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.
As a bynote, I will add that it seems that libfribidi may not be as mature as I have hoped, and if problems keep popping up, I will put it into our code myself (or, more preciseley, try). It will not be an easy task, as it currently carries it's own unicode tables, configure scripts, and so on. Since you vulenteered to help with this.... ;-).
Sure, I can do the unicode tables if you tell me exactly what information you need.
Wouldn't that create strange dependancies between modules? Who currently "owns" the unicode tables?
Shachar