1460445 - Supplied emoji font should get priority over system fonts.

Status: NEW

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

Description

[Mark Straver]

Attachment: emojipedia on nightly with B&W/Win7

As suggested in bug 1295029 I'm filing this as a new bug since it seems the desired behavior wasn't exactly clear and that bug was marked resolved.

The issue is that in the case of emoji, it's bad behavior that system fonts get priority over the embedded/indicated emoji font in font.name-list.emoji:

- Mix of black/white and color emoji (especially if "older" emoticons are being used like basic smileys.
- Mix of styles, e.g. mixing Segoe UI emoji with Twemoji

To provide a uniform rendering of emoji in the browser, whatever font is set as emoji font in font.name-list.emoji should be given *priority* if the presentation is an emoji presentation, and not just be used as a fallback if system fonts don't have specific glyphs available.

See attached screenshot of nightly on emojipedia with a "common" category on Windows 7. Only a few are color, the rest are B&W because the system-installed Segoe UI Symbol font overrules the dedicated emoji font "Twemoji Mozilla"

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to https://bugzilla.mozilla.org/show_bug.cgi?id=1295029#c11)

I again want to point out that this only happens because Emojipedia specifies a font list in their style sheet. If they don't do that, Firefox will correctly select the font specified in font.name-list.emoji to render these smilies.

I would worry having this feature implemented in the way it is described could result in it being described as a bug, like, "Firefox should use my favorite <additional emoji font in the system> automatically than its crappy Twemoji".

It would get further complicated when web font is involved; we certainly don't want to overwrite these as people have been using the codepoints to ship their own site icons. Having font fallback work differently on emoji codepoints will be very confusing for the developers.

IMHO doing something akin to bug 1260637, i.e. blacklist Segoe UI Symbol when Twemoji Mozilla is present, sounds less intrusive. I don't know the feasibility though.

Comment 2

[Mark Straver]

Specifying a font list is extremely common. Web designers will also use replacement (web) fonts for their design and not assuming it covers emoji. If you would have emoji in styled text blocks, the font list specified would disable uniform display of emoji in that text, unless the system just happens to not have any fonts installed that covers any of them.

The situation I see here is that it is specifically an issue with system fonts that do not have good support for emoji, or having a significantly different style, being given priority over the bundled emoji font (or other font of the user's choice from font.name-list.emoji).

I don't think blacklisting fonts is good either unless you can specifically do it ONLY for the emoji ranges -- I wouldn't want to completely lose the ability to display symbols, after all...

If people prefer other emoji fonts than what's bundled, they can set their preference accordingly, so that shouldn't have to be a worry.

So, what the priority should be then for maximum compatibility with web designs but keeping uniformity in emoji:
web fonts > font set in font.name-list.emoji > system fonts

Currently, the order is, AFAIU
web fonts > system fonts > font set in font.name-list.emoji
which is a bug, IMHO, leading to a "ransom note" mishmash of emoji displayed on websites.

Comment 3

[Kevin Cox [@kevincox:matrix.org]]

Attachment: tabbar vs content inconsistency.png

I'm also in the camp of not using crappy Twemoji instead of my system font. This will lead to consistency between apps in my browser and native apps. I think the real problem here is that Firefox is overriding my emoji font at all.

For example you can see in this screenshot that the tab bar is using Twemoji and the content is using my default system emoji font. We obviously can't make this perfectly consistent when the website overrides the emoji font (unless we allow overriding the title font) but it seems that when the website doesn't do that using the system font by default in both the content and the chrome is the most correct thing to do.

I think that forcing an emoji font for the chrome made sense when many OSes didn't have a good emoji font configured but at this point anyone who wants colourful emoji has an OS that gives it to them. It's time to put Twemoji back and the end of the fallback list.

Comment 4

[Mark Straver]

If you hate the bundled font and don't want it used at all, then you could always just disable it in prefs, but please don't ask the rest of us who prefer consistency at least within one displayed application to suffer for it. I don't think the twemoji font was ever moved from it's last-fallback position because the page is obviously using the system emoji font and not twemoji, and this bug is still open.

What you are seeing here is exactly the problem: the inconsistency is there exactly because system fonts get priority over the embedded font in content due to system font hinting, and just confirms the issue why I filed this bug: you're having a mix of emoji styles inside the browser even if the OS has color emoji capabilities, whenever there isn't an exact overlap of emoji font spaces between bundled and O.S.
Take, e.g. this smiley face which is supported in Windows 8.1, and something newer, say ice cube, which isn't. The smiley will be displayed with the system font, the ice cube with the twemoji font. All in the same page... Call me a stickler for consistency but that should always trump whether the glyphs are the same on the system/in other applications or not!

I think we should aim for at the very least consistent display within Firefox, regardless if the page provides system font hints for emoji (because that is just what they are: hints). If people find it jarring re: system integration it'd be as simple as disabling the emoji font in prefs to switch it off entirely and always use the system font as a result.
Please consider finally setting the order to downloaded fonts > application embedded fonts > system font hints.

Comment 5

[Markus.N]

It also happens without font list.

I'm working on a browser AddOn with a UI page that uses emojis as status icons. I haven't provided a font list, but I also get a mixed style of emojis.