Maarten Lankhorst wrote:
I may have slightly misunderstood those flags then. I was under the impression that the FORCE flags would be similar to LRO/RLO.
The only thing that behaves like LRO and RLO are LRO and RLO. Believe you me, no one was more surprised than me when I found out that Windows actually respected them - they are as far away from an end user's experience as you might get (though useful, if you know about them).
The Unicode algorithm keeps talking about setting the paragraph direction based on the first strong direction character in the paragraph (P2). As nice as that may have sound to the people drafting it, it only sort of works in real life. Either way, Window's BiDi doesn't work that way. The paragraph direction is set explicitly by the calling program (or, failing that, by the HDC, or, failing that, by an EXT_STYLE in the Window, you get the picture). This means the end of section 3.3.1, instructing implementors to ignore P2 and P3 in case of "higher-level protocol" apply here. Instead, the paragraph direction is explicitly passed to BIDI_Reorder through the "dwWineGCP_Flags" argument.
Instead they are probably more like LRE/RLE.
It's better to say that LRE and RLE allows one to switch paragraph direction for a specific part of the paragraph. In other words, LRE/RLE are like the paragraph direction, not vice versa.
If that is a real problem I will send in a patch.
If?
I would still rather prefer a real bidi implementation, so that selecting and deleting characters would work properly.
Lost you there completely. What do you mean by "selecting and deleting"? If you mean a BiDi editor, I think you have the tasks confused. Reordering characters in order to get them out on screen for printing has very little to do with string editing. It's one minor small step to start with. Bidi editing is a lot more complex.
To my defense, there was no real clarification for them in the source.
The comments in the code used the same terminology used by Annex 9. The parameters were passed almost directly from the inputs in BIDI_Reorder to ICU's input functions, where they are documented in the ICU documentation. These parameters were also received, pretty directly, from ExtTextOut, again, where they are documented in MSDN. To my eyes, this is the level of documentation any Wine hacker should need. I don't believe code comments should start explaining algorithms, particularly algorithms implemented by a library and documented in an international standard.
And I should warn you that edit control is several magnitudes more complicated. Questions such as cursor position when the cursor is between two letters that are, after reordering (i.e. - on display) not adjacent, what happens if a given cursor location is clicked which has two possible logical locations, and what to do if the user then clicks "del" or types a letter in an RTL or an LTR language. Editing is COMPLEX, and the road is not paved and documented. Matti Alluche wrote a document once that gives specifications for BiDi editing, but after Mozilla implemented it, I whole heartedly recommend that you avoid it. Your best course of action is to find out what Windows does for its edit control and copy that.
Cheers, Maarten
Shachar