"Troy Rollo" wine@troy.rollo.name wrote:
Unfortunately it appears there may be one: LCMapString. If all the things we have discovered about the tables are correct (and I am by no means assuming that they are), then the Microsoft sort key table meets the industrious collection requirements and returns facts in a way that could not be duplicated without duplicating the table (it returns the table entry in literal form, so it couldn't even be represented as a different table).
and another one:
Of course if we can identify a unicode.org version that's much closer to the Microsoft tables so that only minor adjustments are necessary, the industrious collection copyright can be bypassed.
We shouldn't restrict us by an old unicode.org release IMO, newer releases often have major bugfixes and improvements.
All we need is to make sure that any application depending on some API difference is behaving same way under Wine as under Windows. We can do it by writing a comprehensive conformance test case.
There is no need to replicate the whole MS sort weight table, no sane app would depend on it. The real dependence is on result of comparing of the produced sort keys. Since collation table is used by both LCMapString and CompareString I'm fairly sure that fixing any of that APIs simultaneously fixes another one. See the patch I sent to review, it has lots of tests which behave now same way under Wine as under Windows. If we will descover more differences in that area we could easily fix them as well using the same approach.