Closed
Bug 619511
Opened 14 years ago
Closed 13 years ago
ZWJ may affect the font of the following character
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: j_mach_wust, Assigned: jfkthame)
References
()
Details
Attachments
(2 files)
2.06 KB,
patch
|
jtd
:
review+
joe
:
approval2.0+
|
Details | Diff | Splinter Review |
1.51 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 When a font that has no ZWJ character is used for displaying a text that has a ZWJ character, any character that follows the ZWJ will be displayed in a fallback font. Reproducible: Always Actual Results: The character after the ZWJ is displayed in a fallback font. Expected Results: The display should be in the selected display font. The fact that there is no ZWJ character in this font should not affect the display because the ZWJ is invisible anyway. I stumbled on this while researching for another bug and reported it there, and Jonathan Kew answered the following (see https://bugzilla.mozilla.org/show_bug.cgi?id=619286#c4 ): > This occurs because our font-matching code tries to ensure that ZWJ > is processed using the same font as the adjacent characters, so that > there is the possibility of OpenType lookups (or other shaping behavior) > being applied. So, for example, if the default font is a standard Latin > font, but the page includes a run of Arabic or Indic text with embedded > ZWJ characters, we want font-matching to keep the ZWJ in the same font > as the surrounding letters *even though* it may be supported in the > primary (Latin) font. But then, if your font *doesn't* have ZWJ, and so > we are forced to fall back to something else, that fallback propagates > to the next character as well.
Updated•14 years ago
|
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Version: unspecified → Trunk
Assignee | ||
Comment 1•14 years ago
|
||
A testcase that demonstrates this using standard fonts on OS X is data:text/html,<p style="font-family:Copperplate;">foobar foo‍bar where the "b" following ‍ does not appear in the Copperplate font.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → Windows 7
Assignee | ||
Comment 2•14 years ago
|
||
Assignee: nobody → jfkthame
Attachment #499156 -
Flags: review?(jdaggett)
Comment 3•13 years ago
|
||
Comment on attachment 499156 [details] [diff] [review] patch v1 - don't propagate font from ‍ to next char if the ‍ triggered a font switch/fallback Looks good, need a reftest for this.
Attachment #499156 -
Flags: review?(jdaggett) → review+
Assignee | ||
Comment 4•13 years ago
|
||
Comment on attachment 499156 [details] [diff] [review] patch v1 - don't propagate font from ‍ to next char if the ‍ triggered a font switch/fallback Requesting approval-2.0; a low-risk fix that doesn't affect anything outside of the immediate context of the ZWJ character. I don't think the bug is a common issue, but when it does strike, it can be pretty glaring & ugly, so IMO we should go ahead with fixing it.
Attachment #499156 -
Flags: approval2.0?
Assignee | ||
Comment 5•13 years ago
|
||
Reftest for this issue, using @font-face to ensure we've got a font without ZWJ on all platforms.
Updated•13 years ago
|
Attachment #499156 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 6•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/8e3576dbc2f8 (reftest) http://hg.mozilla.org/mozilla-central/rev/70d10ef482f3 (patch)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•