Total bidi regression

Shachar Shemesh shachar at shemesh.biz
Thu Sep 27 01:12:17 CDT 2007


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



More information about the wine-devel mailing list