Dmitry Timoshkov wrote:
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.
I think the source of the problem is a small misunderstanding about what LPK.DLL does on windows. It's not where the reordering algorithm is. That's in uniscribe. What's there is how this reordering algorithm is used for ExtTextOut, DrawText, EditControl and so on. As such, I think it's best if we did the same in Wine. Since the interface to LPK.DLL is undocumented, I think it's best to use something with similar functionality but different name, say "WINELPK".
As for the algorithm itself, I have no objection to it being implemented in wine_unicode. I'm just questioning the wisdom of that DLL. What does Windows use for the same functionality? If it's not there, where is it and why not put it there for wine too?
As for the reordering algorithm, that should be implemented in USP10.dll under (ScriptLayout, ScriptStringGetOrder etc.). I don't see anything wrong with Uniscribe depending on ICU for the time being, in any case.
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.
The reasons I stated against ICU are exactly what's haunting us now. It's too big, it depends on the C++ runtime, and you can't dynamically link it. Other than that, it's a great library. I'm just hoping that if another DLL had these problems rather than GDI, end users would suffer less. Particularly if that new DLL was a soft dependency, (as LPK is in Windows, BTW).
Fribidi would have been great, if only it supported UTF-16. It doesn't, and adding UTF-16 support is non-trivial. There were structural changes that were meant to take place to make UTF-16 support easier, in which case I was planning on implementing it upstream. It is also easy to dynamically link fribidi. However, these changes are taking their time in happening, so we use ICU for the time being. None of this translates to "we'll write our own".
As for taking one of those code's and making them our own, I simply don't see what's there for us to gain. ICU is C++, nothing we can reasonably do will change that. Fribidi is difficult to add UTF-16 support to at the moment, so we gain nothing there too. Writing our own is a headache of magnitudes I don't want to even think of.
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.
Because BiDi already has a well determined place in Windows. That place is uniscribe. Uniscribe does a little of the other things as well, but quite frankly, not much. At least not that I could make out. As such, I vote for implementing stuff where it should be. This also has the extra benefit of making uniscribe the one depending on ICU, not GDI. Assuming GDI's dependence on Uniscribe is through LPK, and that LPK is a soft dependency, this means that users that don't have the right C++ runtime, don't want the extra size, or can't get ICU depending DLLs loaded for whatever other reason will still be able to use Wine (though not Uniscribe, which I think is only fair).
Shachar