epoll, LSB (was: Re: Problem roundup)
wine-devel at shemesh.biz
Mon Nov 22 04:11:57 CST 2004
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
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).
Lingnu Open Source Consulting ltd.
More information about the wine-devel