Alexandre Julliard wrote:
Shachar Shemesh wine-devel@sun.consumer.org.il writes:
- 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