Symmetric swapping only working for 8-bit characters

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: smontagu, Assigned: smontagu)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Assignee)

Description

11 years ago
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.
(Assignee)

Comment 1

11 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

11 years ago
Created attachment 270875 [details] [diff] [review]
Patch
Assignee: nobody → smontagu
Status: NEW → ASSIGNED
Attachment #270875 - Flags: review?(roc)
(Assignee)

Comment 3

11 years ago
Created attachment 270892 [details] [diff] [review]
Updated patch

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

11 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
(Assignee)

Comment 6

11 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 10

11 years ago
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.