Created attachment 270334 [details] Reduced testcase In the attached testcase all three lines should show similar behaviour, with the mirrored characters pointing one way in the "a b" column and the other way in the Hebrew and Arabic columns. The first two lines are correct; the third is not, and so for all codepoints above 0xFF. (See http://smontagu.org/testcases/symmswap.5.0.0.html for a more comprehensive testcase). This regressed between 2007-06-12 and 2007-06-13 in builds with new textframe turned on, which is all I have to test on here and now.
This is a regression from the text run word cache: if I change the test case so that the ltr cases come after the rtl cases, then the mirrored characters appear rtl in the ltr context. Roc, would it be overkill to add an rtl flag to the hash key?
Created attachment 270875 [details] [diff] [review] Patch
Assignee: nobody → smontagu
Status: NEW → ASSIGNED
Attachment #270875 - Flags: review?(roc)
Created attachment 270892 [details] [diff] [review] Updated patch Oops, the original patch is bitrotted already.
Comment on attachment 270892 [details] [diff] [review] Updated patch + aKey->mIsDoubleByteText + aKey->mIsRTL; Make this aKey->mIsRTL*2 for a slightly better hash code...
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Homework assignment: are there any other cases where a "word" (as defined by the textrun word cache) with the same sequence of unicode codepoints will not be rendered with the same glyphs? Things like danda and double danda in Indic script will presumably be in different fonts already. We need to check what happens in locales where the OS does contextual numerical substitution.
I hope you can solve that homework problem :-) I hope that contextual analysis generally does not span word boundaries...
BTW could you make reftests for this bug, and/or any weird contextual analysis situations you come up with?
Will do. I already checked in a reftest based on attachment 270334 [details]: http://mxr.mozilla.org/seamonkey/source/layout/reftests/bidi/386339.html http://mxr.mozilla.org/seamonkey/source/layout/reftests/bidi/386339-ref.html
Created attachment 271207 [details] Arabic shaping testcase Here's another case fixed by my patch, admittedly pathological and not likely to come up in real-world contexts. An Arabic word with left-to-right override needs to be reversed before rendering, and then shaping is applied. In this case you have the same word with and without left-to-right override, and (without the patch) the second occurrence uses the shaped forms from the first occurrence; in other words the first letter is a final form and the last letter is an initial form.
This bug's reftest fails on my Linux laptop, using a trunk checkout from today. Here are tinyurls for the testcase and reference case screenshots: Testcase: http://preview.tinyurl.com/yrocgr Reference: http://preview.tinyurl.com/2d2r8n Looks like a spacing / sizing issue of some sort.
You need to log in before you can comment on or make changes to this bug.