While I have no experience contributing code to wine itself so far, BiDi or not, I smell a high-level design choice here. If the new revision to the Unicode algorithm looks superior, my first idea would be to try rebasing the code on that and then explicitly overriding it for Windows quirks.
I don't know enough about wine's code or performance issues to advocate when that redirection should take place. I suppose it could be done during compilation and linking, during runtime, or even by just hard-coding and commenting "standards" and "quirks" versions in the source. Mine's not the most informed opinion though so I would take it with a grain of salt. -Kyle On 10/04/2013 07:54 AM, Aric Stewart wrote: > Hello, > > So Unicode 6.3 was just recently released. One of the things it features is > an updated BIDI (Bidirectional) algorithm. This is revision 29 to the > algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) > Looking at the code I moved from gdi32 to usp10, it looks like the existing > code is based off of revision 17. This implementation was originally by > Shachar and Maarten. I simply integrated it into uniscribe. > > I am tempted to update our code to match the revision 29 version of the > algorithm. But this raises a question. Right now our code mostly correctly > mimics Windows. It may be that I am not testing the correct edge cases that > would reveal if windows is coded to a later version of the algorithm or not. > But if we update to revision 29 then we will almost assuredly be using a > later version of the algorithm. > > What is more important to us in this regard? Do we want to have the latest > algorithm based on the unicode standard, or do we want to try to match the > algorithm that Windows makes use of? > > Thanks! > -aric > >
