Closed Bug 467722 Opened 11 years ago Closed 9 years ago

Inconsistent font selection (?) with zwj, Chinese characters

Categories

(Core :: Layout: Text and Fonts, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: jfkthame)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(3 files)

Attached file with bounce
The two files "with bounce" and "without bounce" should look the same.

Based on gfx/thebes/crashtests/402307-1.html.
Attached file without bounce
Weird. Jonathan should probably look at this...
WFM
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Test checked in: http://hg.mozilla.org/mozilla-central/rev/08cb6bce6d83
Flags: in-testsuite+
The reftest 467722 started failing for me, so I've been looking into it, and there is indeed a font-selection bug that underlies this. The problem can be illustrated on OS X 10.6 with a testcase:

data:text/html,<div style="font-size:100px">a&#x9BB8;b&#x9143;c&#x9BB8;d

Look closely at the first and third CJK characters here; they are the same character code, but in FF3.6 and current trunk builds, they are resolved to different fonts (assuming default font preferences).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The problem occurs because gfxFontGroup::WhichPrefFontSupportsChar may set the mLastPrefFirstFont flag even if it was actually checking one of the later languages in the prefLangs array. This patch fixes it by ensuring that mLastPrefFirstFont is only set if the character was found in the very first pref-font checked.
Assignee: nobody → jfkthame
Attachment #494503 - Flags: review?(jdaggett)
Comment on attachment 494503 [details] [diff] [review]
patch v1 - don't set mLastPrefFirstFont unless it really was the first

Ouch, wish we had caught this earlier...
Attachment #494503 - Flags: review?(jdaggett) → review+
Comment on attachment 494503 [details] [diff] [review]
patch v1 - don't set mLastPrefFirstFont unless it really was the first

Requesting approval2.0; this fixes a correctness error in our handling of font preferences, as shown by the testcase in comment #5. The patch is very low-risk, as it clearly has no effect outside of the pref-font search function.
Attachment #494503 - Flags: approval2.0?
http://hg.mozilla.org/mozilla-central/rev/a722e6bdd003
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.