Closed Bug 386339 Opened 17 years ago Closed 17 years ago

Symmetric swapping only working for 8-bit characters

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: smontagu, Assigned: smontagu)

References

()

Details

(Keywords: regression, testcase)

Attachments

(3 files, 1 obsolete file)

Attached file 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?
Attached patch Patch (obsolete) — Splinter Review
Assignee: nobody → smontagu
Status: NEW → ASSIGNED
Attachment #270875 - Flags: review?(roc)
Attached patch Updated patchSplinter Review
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+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
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?
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.

Attachment

General

Created:
Updated:
Size: