Alexandre Julliard wrote:
As I said, I want to see working code first.
My original plan was to submit the patch under the assumption it won't get included until other patches come in. I don't want to lose code (again).
And frankly, this ICU library sounds pretty broken, I'm not sure you want to use that.
Me neither, but I have worked so %$%^Y*!#@)* hard already, that I might as well finish the patch. I just told a friend that I don't remeber ever working so hard on so little code, knowing this code is highly likely to get dumped.
Currently the choices are: 1. Use ICU, with all the implications. I'm trying to keep those implications down to a minimum. 2. Use Fribidi, converting each string to UCS-4 and back to UTF-16, hoping that the promises made to support UTF-16 natively will be kept. More precisely, the promises were that they are going to make interface changes that are planned anyways, and those will make it easier for me to add native UTF-16 support. This has been *awfully* delayed, to the point of showing no progress at all. 3. Reimplement everything. It only sounds like the best option to those who don't understand what it means. I'm not sure "2" won't prove faster.
Right now I'm going to move ahead with 1, under the assumption that plugging out the engine and replacing it is not a major problem. I would then also suggest moving it into a seperate DLL, so that the ugly code can be shipped as an optional component ("apt-get install wine-bidi" if you want it - it'll be a single file plus dependancies).
Shachar