Fall back on other fonts for unsupported color emoji glyphs |
|||||
Issue descriptionChrome on Windows doesn't support rendering the Noto Color Emoji font, per upstream bug which has more info: https://github.com/googlei18n/noto-emoji/issues/43 When rendering color emojis using this font the emoji are completely blank (e.g. some content on the page is not intelligible). Fallback on the default font does not happen here. The default font however does support rendering color emoji. It would be nice if font fallback could happen at least for the emoji glyphs so this content wouldn't turn invisible for these fonts. Currently these glyphs are blank, and if you highlight them and right click you can see Search Google for "<emoji>.." using the default font. Repro page: http://dev.pbos.me/repro/noto-color-emoji-windows/ Related Google-internal bug: https://issuetracker.google.com/68723914
,
Nov 8 2017
+cc, I think kulshin@ would've been taking a look at this but they're no longer with us. I got your usernames recommended as people who might know. Do you know who could help triage this?
,
Nov 8 2017
This really should fall back on the monochrome glyphs in the Noto Color Emoji font however it looks like those are missing.
,
Nov 8 2017
Falling back on monochrome glyphs sounds reasonable, but if that's the case then web developers can't (easily) provide a fallback color emoji font (prefer Note Color Emoji, fall back on other-font-format color emoji). It would be nice if Blink could keep cycling the font-family list and eventually end up with the system font for those glyphs (probably better than falling back on system font directly as web developers can provide a fallback font for systems that don't support this font. I was also a bit surprised that I'm not getting the black [] placeholder glyph, is it possible that the system thinks this glyph is properly rendered?
,
Nov 8 2017
It's a bit more complicated than that, we need to respect the wishes of the web author and the font fallback order. In this case the font *has* the requested codepoint but lacks outlines for it. That is a really odd case and one the current font stack was not designed for. We could probably special case that and treat it as if the font didn't have the codepoint in question. With something like font-presentation: emoji we might be able to change the fallback logic to prioritize fonts with a color glyph over a monochrome one. That would require a spec change however. https://drafts.csswg.org/css-fonts-4/#font-presentation-desc
,
Nov 8 2017
Consider color over monochrome to be vastly out of scope for this issue report then, just implications of it that I thought of if it was implementation-defined.
,
Nov 8 2017
No no, thank you for the report. We need to fix this it's just not clear *how* to do that yet.
,
Nov 9
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 9
We now support the underlying color format on all platforms. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pbos@chromium.org
, Nov 8 201771.9 KB
71.9 KB View Download