1661570 - Changes in bug 1371386 break icon webfonts that share Emoji codepoints

Status: RESOLVED FIXED

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

Description

[Dennis Schubert [:denschub][OOO, back Aug 11]]

First, I'm sorry for filing a WebCompat-bug as a regression of a fix that fixes a WebCompat bug. :(

In the patch that landed in bug 1371386, we adjusted the font selection behavior so that the system's emoji font would be preferred over specified fonts if an emoji is to be drawn. Unfortunately, this fix seems to not be web compatible.

I noticed this in an application using the Entypo web font. You can see an example of this at http://fontello.github.io/entypo/demo.html - in Firefox, some icons are rendered using the emoji font, others are rendered from the icon font. All icons here should be in a consistent style and always black and white. Chrome and Safari render the example correctly.

[Tracking Requested - why for this release]:

This is a change in behavior that regressed at least one icon webfont and could break a range of icon fonts. Entypo is affected, and while I'm not aware of other icon fonts that share the emoji range, this is probably not good and doesn't match other browsers.

Comment 1

[Jonathan Kew [:jfkthame]]

Sigh.... there's just no pleasing everyone!

Chrome and Safari render the example correctly

On the other hand, neither Chrome nor Safari gets the examples in bug 1371386 as correct as we do now. :)

Anyhow....maybe a good heuristic here would be that if there's a webfont in the explicit font-family list that supports the codepoint, then we should accept that choice even if it doesn't match the "preferred" (per Unicode properties) emoji- or text-style rendering, on the grounds that if the author has named a specific font resource, they really do expect that font to be used.

I'll put together a patch to try that and see how things look.

Comment 2

[Jonathan Kew [:jfkthame]]

(We could also argue that if the author explicitly does not want a color-emoji font to be used for Unicode codepoints that are specified to have emoji-style presentation by default, they should have used the U+FE0E variation selector to express their preference for a text-style rendering. But let's see if we can make improvements to our heuristics so as to magically do "the right thing" in more cases.)

Comment 3

[Dennis Schubert [:denschub][OOO, back Aug 11]]

I'm also happy to do a bit more digging into other web-iconfonts to gauge how big the issue is. Font Awesome has no issues, none of the fonts at fontello.com have issues, and Entypo got its last update in 2015 and the download links on the website are dead. Although it probably would be hard to estimate how many sites are using Entypo...

Comment 4

[Jonathan Kew [:jfkthame]]

I suppose we (or Google?) may have web-crawl data that would in theory make it possible to get an idea. But I think we can do something to make our behavior smarter here, so let's see how that goes.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1661570 - Allow webfonts to be used for emoji-default codepoints even if they don't provide color glyphs. r=m_kato

Comment 6

[Jonathan Kew [:jfkthame]]

The change I'm proposing here (in the attached patch) is to distinguish between cases where there is an explicit requirement in the encoded text for emoji-style rendering, because the Emoji-style variation selector has been used or a skin-tone modifier is present, and cases where the choice of emoji-style rendering is the default according to Unicode property data, but not explicitly called for by the text.

In the explicit case, we'll continue to prefer a color font (if available), but for characters where the choice of color-emoji rendering is just a Unicode default, this patch will allow the author-specified webfont (such as an icon font) to be used even if this means we don't get the color glyph that would normally be expected from font fallback. The assumption is that if the author has specified a certain font resource (not just relying on the system's installed fonts), they really do want that font to be used.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4ed43385c9b2
Allow webfonts to be used for emoji-default codepoints even if they don't provide color glyphs. r=m_kato

Comment 8

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/4ed43385c9b2