Latest version of Symbola is not a good fallback font for IDEOGRAPHIC SPACE (U+3000)
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox76 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
Details
Attachments
(1 file)
Mentioned on twitter: https://twitter.com/CharlotteBuff/status/1242507720563085313
The latest Symbola has a visible glyph for U+3000 (which seems a strange thing to do as a default rendering...), so when font fallback is happening, its presence in gfxPlatformGtk::GetCommonFallbackFonts results in an unwanted symbol where a space would be expected.
We could rearrange the fallback fonts list to try and prefer a real CJK font, or at least Droid Sans Fallback, but given the unpredictability of available fonts on Linux systems, perhaps a better option is to make U+3000 one of the space-like chars for which we will synthesize a blank glyph of a standard width instead of resorting to system font fallback.
Assignee | ||
Comment 1•4 years ago
|
||
Assignee | ||
Comment 2•4 years ago
|
||
Hmm -- while I think it's worth doing this, I'm not sure whether it'll actually fix things for the original user; I don't have a specific URL, but it's possible they're viewing a page where Symbola is explicitly included in the font-family
list, rather than hitting it via fallback.
Assignee | ||
Comment 3•4 years ago
|
||
Just to follow up, discussion on twitter indicated that the user had Symbola in their font prefs, so it wasn't just about font-fallback behavior in Firefox. Nevertheless, the patch here seems worth taking for general robustness, even though it won't solve the "problem" when Symbola is explicitly requested via font-family or font prefs.
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/395b889fe028 Synthesize a space for U+3000 in preference to relying on font fallback. r=heycam
Comment 5•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Description
•