Closed
Bug 386339
Opened 17 years ago
Closed 17 years ago
Symmetric swapping only working for 8-bit characters
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: smontagu, Assigned: smontagu)
References
()
Details
(Keywords: regression, testcase)
Attachments
(3 files, 1 obsolete file)
577 bytes,
text/html
|
Details | |
5.96 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
253 bytes,
text/html
|
Details |
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.
Assignee | ||
Comment 1•17 years ago
|
||
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?
Assignee | ||
Comment 2•17 years ago
|
||
Assignee | ||
Comment 3•17 years ago
|
||
Oops, the original patch is bitrotted already.
Attachment #270875 -
Attachment is obsolete: true
Attachment #270892 -
Flags: review?(roc)
Attachment #270875 -
Flags: review?(roc)
Comment on attachment 270892 [details] [diff] [review] Updated patch + aKey->mIsDoubleByteText + aKey->mIsRTL; Make this aKey->mIsRTL*2 for a slightly better hash code...
Attachment #270892 -
Flags: superreview+
Attachment #270892 -
Flags: review?(roc)
Attachment #270892 -
Flags: review+
Assignee | ||
Comment 5•17 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Assignee | ||
Comment 6•17 years ago
|
||
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?
Assignee | ||
Comment 9•17 years ago
|
||
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
Assignee | ||
Comment 10•17 years ago
|
||
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.
Comment 11•17 years ago
|
||
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.
Description
•