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?
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).
Wouldn't that create strange dependancies between modules? Who currently "owns" the unicode tables?
The Unicode tables are part of libwine_unicode, so that they can be shared between all the modules that need them. So that's not a problem.