Shachar Shemesh schreef:
Alexandre Julliard wrote:
Actually the proper place would be libwine along with the rest of the Unicode support.
I've spent the past hour downloading 12% of the git repository, so I'm unable to look at current Wine code for at least the next 24 hours :-(.
From memory, libwine contains mostly tables and stuff, not actual
algorithms. Wouldn't it be better to place the tables at libwine, but the algorithm at uniscribe, if only to follow Window's design of things?
Also, I suspect it might be necessary, at some point in the extreme distant future, to do some deviation from the Unicode algorithm. It's pretty far away, as we're talking about nuances that are hard to pick if you don't know your stuff, but there are places where Windows can be said to be either implementing an old version of the standard, or implementing its own idea altogether.
My original plan was to import the fribidi code into a subdirectory of the wine tree, and make the necessary changes there.
Actually dlls/gdi32/bidi.c now already has a full implementation of the bidirectional algorythm, you could easily take it out there and replace it by a (reverse)memcpy depending on which forced direction, since the force direction flag overrides all other flags that determine direction. It shouldn't be much of an effort to implement whatever uniscribe needs using bidi.c..
On a related note - I haven't been able to get an answer to that one, not even through experimentation. Does anyone know whether Windows' Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates is crucially important when reordering characters.
Shachar
I'm guessing utf-16, not 100% sure though.
Maarten