"Shachar Shemesh" wine-devel@shemesh.biz wrote:
We don't really have to write it from scratch, porting an existing code would suffice, but a difference between unicode char width (16 vs. 32 bit) makes it impossible to use any system unicode APIs.
Lost you there. We are currently using ICU precisely because it does have UTF-16 support.
Another reason to have an internal implementation is to not depend on possible differences between implementations, differences in collation tables is an obvious example here.
Lost you there again. There is no dependence of BiDi on collation, or we would use ICU for a lot more than only BiDi. ICU is an entire Unicode solution, and does have all of those things.
That's my point here: we don't need an external unicode solution, we already have one, we just need to add missing parts, and we really don't want to depened on ICU or anything else.
Seriously, I don't see anyone here volunteering to maintain the BiDi code, and I don't have the resources to chase Unicode around. I really think using an external library is the right thing to do.
I don't understand you: you were arguing some time ago that ICU is too bad as an external library and freebidi is not ready to be used in Wine. Now you want to use that approach anyway. It's really time to rethink your stance and either import an existing bidi code to Wine and use it as a base for further improvements, or find a replacement for ICU and start to use it.
String folding, case mapping, character types, collation, decomposition, code page conversions are already implemented in wine_unicode, I don't see why bi-di can't added there as well. If we would think in terms of laziness Wine would be nowhere these days.