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.
Open the testcase in Safari and in Firefox
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).
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]
Created attachment 2363 [details]
Created attachment 2364 [details]
Created attachment 2366 [details]
With the current ToT, not having applied this patch, I see line 2 rendered correctly not as shown or
(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]
Looks good. It would be better to replace 0x202D and 0x202C with a #define.
Created attachment 2417 [details]
Replaced 0x202C and 0x202D with a #define as suggested by rjw.
Comment on attachment 2417 [details]
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.