"Shachar Shemesh" wine-devel@shemesh.biz wrote:
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".
One of the reasons why Alexandre decided to add unicode support in wine_unicode is that it's completely not documented how it's done in Windows, especially since it's implemented differently in different Windows platforms. It would be plain stupid to create another custom Wine dll while already there is a place for that stuff.
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?
See above.
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.
As soon as you or anybody else implement uniscribe APIs you can start arguing where to place core of it. But still, personally I don't see nothing wrong to implement it in wine_unicode and use that as a backend, as currently done for everything else like FoldString or CompareString.
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".
What do you mean by that? Why adding UTF-16 is not trivial? For the starters we can completely ignore surrogates, and Windows does not have unicode chars above 0xffff anyway.