Total bidi regression

Shachar Shemesh shachar at
Wed Sep 26 16:27:44 CDT 2007

Maarten Lankhorst wrote:
> Shachar Shemesh schreef:
>> Maarten Lankhorst wrote:
>>> If you want it back try replacing this in font.c:
>>> change FORCE to LOOSE, it should work then.
>> I'm not sure what you are suggesting.
>> WINE_GCPW_FORCE_RTL only appear on line 1089 of bidi.c, which reads
>>>    case WINE_GCPW_FORCE_RTL: forcedir = R; baselevel = 1; break;
>> I'm not sure what you are suggesting I do with it.
>> Either way, the change you are suggesting will only affect (if I
>> understand the code correctly) the paragraph direction setting, where as
>> I'm experiencing total lack of BiDi reordering of any kind.
> Before arguing, you should really give it a try, it helps. ;-)
Sure thing. Just what, exactly, is "it"? What do you suggest I change,
and what to? I am really asking you to be less ambiguous.

If you mean to change the "FORCE" to "LOOSE", then things are slightly
better in that same direction runs are at least now being reordered, but
things are still at a huge regression. Neutrals (at least some neutrals,
like space) seem to be incorrectly handled in mixed paragraphs (I'm not
sure, as this could be a font problem as well). Also, and this is
confirmed, there is now no way to request a right to left paragraph, at
all. Numbers I haven't checked.

Again, I may have misunderstood what change you meant for me to try. If
you don't want to be misunderstood, try just sending a patch. I'm more
than willing to help, but not if it means trying to decrypt what code
changes you are suggesting, or where in the 1200 lines file they are
meant to be.
> forcedir means basically force every not-control character to that
> direction.
Which doesn't ring a bell as far as the Annex 9. I don't recall any such
thing there. They had a notion of "paragraph direction", which did
affect NEUTRALS, and only if they were placed on the border between
conflicting direction runs (and also the initial nesting level, of
course). The ONLY thing I recall that could cause a hard RTL or hard LTR
character to be rendered in the opposite direction was an LRO/RLO, which
was never used here. Thus, I say again, the change you offer seem out of
place in relation to the place you offer it, and it seems to me that
there is an error in your implementation of Annex 9.
> Cheers,
> Maarten

More information about the wine-devel mailing list