Summary: Under certain conditions, reordering of the letters or Unicode mirroring occurs in visually- ordered Hebrew, instead of plain left-to-right ordering and no mirroring. To reproduce: Open the testcase in Safari and in Firefox Expected: Safari should render it like Firefox does (that is, characters should be rendered from left to right unchanged and in the order in which they appear in the source). Actual: Line 1: the full stop (.) and Hebrew letter Bet are rendered in the wrong order. Line 2: the left parenthesis is rendered as a right parenthesis. Line 3: the letter a and the Hebrew letter Aleph are rendered in the wrong order. Line 4: there is no space between the hyphen-minus (-) and the Hebrew letter Aleph. See screenshots for expected and actual. Analysis: Currently visual ordering is accomplished by reversing the order of characters prior to drawing, assuming ATSUI will re-reverse. The problem is that sometimes ATSUI's transformation is not as trivial, and includes more complex reordering and mirroring. The proposed patch accomplishes visual ordering by enclosing the text between Unicode LRO and PDF characters instead of reversing it. The LRO effectively tells ATSUI not to do any re-ordering or mirroring but just render visually from left to right. Since this is a rendering-only (not layout) bug, there's no layout test.
Created attachment 2362 [details] testcase
Created attachment 2363 [details] actual rendering
Created attachment 2364 [details] expected rendering
Created attachment 2366 [details] Proposed patch
With the current ToT, not having applied this patch, I see line 2 rendered correctly not as shown or described above.
(In reply to comment #5) > With the current ToT, not having applied this patch, I see line 2 rendered correctly not as shown or > described above. Could this be due to the ATSUI issue mentioned in <http://bugzilla.opendarwin.org/show_bug.cgi? id=3435#c6>? I took the screenshot with the Standard font set to Lucida Grande 14.
Comment on attachment 2366 [details] Proposed patch Looks good. It would be better to replace 0x202D and 0x202C with a #define.
Created attachment 2417 [details] revised patch Replaced 0x202C and 0x202D with a #define as suggested by rjw.
Comment on attachment 2417 [details] revised patch Good to go. I'll commit. Thanks Mitz.
Reporter, please mark this bug as Verified if this issue has been fixed in the latest TOT Webkit.