When using a font that contains glyphs for bidi control characters LRO and PDF, each run of visually- ordered Hebrew is enclosed by those glyphs. To reproduce: You need a font that contains those glyphs. For the testcase, the version of Arial that comes with Windows XP will do (disable all other versions of Arial). Open the testcase. Expected: Not to see control-character glyphs on either side of the Hebrew text (see screenshot). Actual: The Hebrew letters are enclosed by the LRO and PDF glyphs. Analysis: the fix for bug 3545 encloses each run of visually-ordered Hebrew in LRO-PDF, and adjusts the from and to members to include the LRO and PDF. It shouldn't. ATSUI will respect the LRO even if it occurs before the first character to be rendered. The patch corrects this by making the from-to range include only the original characters in the run, leaving the control characters outside.
Created attachment 2813 [details] Testcase
Created attachment 2814 [details] actual rendering
Created attachment 2815 [details] expected rendering
Created attachment 2816 [details] Proposed fix
Confirmed, weird stuff, hebrew is nice tho :P
Comment on attachment 2816 [details] Proposed fix r=me
Comment on attachment 2816 [details] Proposed fix Looks great to me too, although I don't see the need for the cast to (int) in the expression: (int)run->length - 1 since subtracting 1 from the unsigned value is going to make it into a signed value anyway.
(In reply to comment #7) > (From update of attachment 2816 [details] [edit]) > Looks great to me too, although I don't see the need for the cast to (int) in > the expression: > > (int)run->length - 1 > > since subtracting 1 from the unsigned value is going to make it into a signed > value anyway. > Tell that to the compiler. Without the case, it says "warning: signed and unsigned type in conditional expression".
Landing a fix and adding a manual test, since our layout test font doesn't include glyphs for LRO and PDF.