Firefox Mac: some icons in Black and white Noto Emoji appear in colour

Question

Firefox Mac: some icons in Black and white Noto Emoji appear in colour

Lorp opened this issue 2 years ago · 35 comments

Many icons in Noto Emoji black-and-white appear in colour when it is used as a webfont in Firefox. Safari and Chrome show b/w glyphs only, as expected. The colour glyphs are from the system Apple Color Emoji font. Firefox v100.0, MacOS 12.3.1.

<!DOCTYPE html>
<html>
<head>
<link href="https://fonts.googleapis.com/css2?family=Noto+Emoji&display=swap" rel="stylesheet">
</head>
<body style="font-family: Noto Emoji">
😀 😃 😄 😁 😆 😅 😂 🤣 😭 😉 😗 😙 😚 😘 🥰 😍 🤩 🥳 🙃 🙂 🥲 🥹 😋 😛 😝 😜 🤪 😇 😊 ☺️ …
</body>
</html>

Answer 1 · 2022-05-04T14:53:37.000Z

maybe it's related to googlefonts/nanoemoji#368 (comment)

a sequence with a fitzpatrick modifier must be colorful so reject a font that cannot provide a colored result

/cc @behdad @rsheeter

Answer 2 · 2022-05-04T15:07:21.000Z

In case it’s useful (e.g. possible invisible characters), I generated the list of emojis by copy-pasting from the character table at Google Fonts: Noto Emoji.

Answer 3 · 2022-05-04T15:22:24.000Z

Safari 15.4

Answer 4 · 2022-05-04T15:22:58.000Z

Chrome 101.0.4951.54

Answer 5 · 2022-05-04T15:32:10.000Z

In fact only Chrome seems to be getting it right. In many, perhaps all, cases with sequences, Safari shows decomposed characters.

Examples: man and woman with heart (and other combos), keycap digit 0, keycap digit 1 (etc.), rainbow flag, transgender flag

Answer 6 · 2022-05-04T15:40:02.000Z

Current Noto Emoji page in latest Firefox…

Answer 7 · 2022-05-04T17:37:35.000Z

Those seem to have Extended_Pictographic property in Unicode:
https://unicode.org/Public/UNIDATA/emoji/emoji-data.txt

No idea what that property means.

And yes, the same code block seems to force picking up a colorful font for them:
https://searchfox.org/mozilla-central/source/gfx/thebes/gfxTextRun.cpp#3067-3091

Answer 8 · 2022-05-04T17:42:38.000Z

I guess this should be filed as FireFox bug. is there something to be done from the font side to fix/work around this?

Answer 9 · 2022-05-04T17:42:42.000Z

Those seem to have Extended_Pictographic property in Unicode: https://unicode.org/Public/UNIDATA/emoji/emoji-data.txt

No idea what that property means.

https://www.unicode.org/reports/tr44/#Extended_Pictographic

Answer 10 · 2022-05-04T17:44:54.000Z

Humm. That's not it. Most of the emoji should be in there...

Answer 11 · 2022-05-04T17:52:02.000Z

I see what's going on. Firefox only looks at properties Emoji and Emoji_Presentation, but not Extended_Pictograph:

https://searchfox.org/mozilla-central/source/intl/unicharutil/util/nsUnicodeProperties.h#123-134

For stability reasons the two former properties have not been updated to include more emoji. The definition of the latter though allows for non-stability:

= Yes for pictographic symbols, as well as reserved ranges in blocks largely associated with emoji characters. This enables segmentation rules involving emoji to be specified stably, even in cases where an existing non-emoji pictographic symbol later comes to be treated as an emoji.

So if Firefox wants to be consistent, it should also include Extended_Pictograph as Emoji_Presentation.

That doesn't help @Lorp's case. But explains why only some emoji get colorful.

A Firefox bug is in order, yes.

Answer 12 · 2022-05-04T18:00:09.000Z

is there something to be done from the font side to fix/work around this?

Adding a dummy color table...

Answer 13 · 2022-05-04T18:04:53.000Z

https://bugzilla.mozilla.org/show_bug.cgi?id=1767842

Answer 14 · 2022-05-04T18:27:56.000Z

@Lorp Are the "colorful" characters perhaps those where there's an explicit U+FE0F variation selector present in the document? (Could you provide the complete test file you're using? Thanks.)

Answer 15 · 2022-05-04T18:34:18.000Z

@Lorp Are the "colorful" characters perhaps those where there's an explicit U+FE0F variation selector present in the document? (Could you provide the complete test file you're using? Thanks.)

To me those are the ones with Emoji=true.

Answer 16 · 2022-05-04T18:56:11.000Z

But lots of chars with Emoji=true are not appearing colorful, e.g. the first char in Laurence's original comment is U+1F600 (😀), which has both Emoji=true and EmojiPresentation=true, according to https://unicode.org/Public/UNIDATA/emoji/emoji-data.txt.

The first "failure" there is ☺️, which is U+263A U+FE0F. So I wondered if all the other failures are also sequences with U+FE0F attached.

Answer 17 · 2022-05-04T18:59:10.000Z

You're right. My bad. I spot-checked a few (telephone vs white telephone, hot pepper vs eggplant, etc...)

Answer 18 · 2022-05-04T18:59:33.000Z

You're right. My bad. I spot-checked a few (telephone vs white telephone, hot pepper vs eggplant, etc...)

I still think the Firefox bug I filed is legitimate.

Answer 19 · 2022-05-04T19:03:03.000Z

Here is my test file @jfkthame

noto-emoji-test.html.zip

Answer 20 · 2022-05-04T19:16:26.000Z

I think you’re onto something. The test file above uses pasted emojis, so it’s difficult to tell what exact Unicode is being used. However…

☺ ☺&#xFE0F; &#x263a; &#x263a;&#xFE0F;

Answer 21 · 2022-05-04T19:19:40.000Z

So are these malfunctioning because they are based on pre-Emoji BMP Unicodes, with the FE0F suffix intended to trigger Emojiness?

Answer 22 · 2022-05-04T19:25:00.000Z

I see 241 FE0F's.

Answer 23 · 2022-05-04T19:32:55.000Z

I wonder if MacOS added them when I copy/pasted them from Google Fonts, or Google Fonts inserts them into the character tables. I think the latter. The Character Viewer panel in MacOS does not add them, based on a test with 263A.

Answer 24 · 2022-05-04T19:38:10.000Z

The Character Viewer panel in MacOS does not add them, based on a test with 263A.

That depends. If you view the panel by "Unicode", select the Miscellaneous Symbols block, and double-click U+263A, you get just that. But if you view by "Emoji", select the Smileys & People view, and double-click the "smiling face" emoji (the 11th entry for me, I guess it might vary on different OS versions), it'll insert U+263A U+FE0F.

Answer 25 · 2022-05-04T19:44:02.000Z

If this issue is all about U+FE0F, the questions concerning use of this font are:

which environments append U+FE0F to these characters to trigger emoji presentation?
what is the correct way to respect U+FE0F?

Indeed @jfkthame, the 11th symbol in the Emoji section yields U+263A U+FE0F.

Answer 26 · 2022-05-04T19:48:12.000Z

So are these malfunctioning because they are based on pre-Emoji BMP Unicodes, with the FE0F suffix intended to trigger Emojiness?

I believe so. When the U+FE0F selector is present, Firefox takes this as a strong request for an emoji-style presentation, and therefore looks for a font that supports one of the color-glyph technologies. (If we don't do this, then people tend to get ugly b/w symbols from fonts like DejaVu that happen to be specified in font-family, when they expected colorful emoji.)

For characters that have EmojiPresentation=true but are used without U+FE0F, we'll default to looking for an emoji-style font, but less strongly: if you explicitly provide a webfont for them, we'll use it regardless of its color-ness.

Answer 27 · 2022-05-04T19:50:52.000Z

In general, this seems to be a hard question, and I'm not sure there's any perfect heuristic. There's a fundamental tension between "respect the presentation style specified by the Unicode sequence" and "respect the font specified in CSS font-family", and we've been through a few iterations of trying to find a balance here.

Answer 28 · 2022-05-05T22:54:04.000Z

Since using a custom emoji font is (currently) the rare case, would it make sense to recommend custom emoji fonts are invoked via @font-face { font-family: MyEmojiFont; src: ...; unicode-range: <emoji-chars>; } and for Firefox to use inclusion in an explicit unicode-range as a strong request to use what’s in the webfont?

Answer 29 · 2022-05-16T17:20:55.000Z

The response already contains both U+263A and U+FE0F specified in the unicode-range:

@font-face {
  font-family: 'Noto Emoji';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notoemoji/v24/bMrnmSyK7YY-MEu6aWjPDs-ar6uWaGWuob-r0jwsS-FGJSsYRxHOpTV331nyNs0.9.woff) format('woff');
  unicode-range: U+200d, U+261d, U+2620, U+2639-263a, U+2665, U+270a-270d, U+2728, U+2763-2764, U+2b50, U+fe0f, U+1f31a-1f31f, U+1f32b, U+1f383, U+1f389-1f38a, U+1f3fb-1f3ff, U+1f440-1f450, U+1f463-1f465, U+1f479-1f47b, U+1f47d, U+1f47f-1f480, U+1f485, U+1f48b-1f48c, U+1f493-1f49f, U+1f4a2, U+1f4a4-1f4a6, U+1f4a8-1f4ab, U+1f4af, U+1f525, U+1f573, U+1f590, U+1f595-1f596, U+1f5a4, U+1f5e3, U+1f600-1f644, U+1f648-1f64a, U+1f64c, U+1f64f, U+1f90c-1f925, U+1f927-1f92f, U+1f932-1f933, U+1f970-1f976, U+1f978-1f97a, U+1f9a0, U+1f9b4-1f9b7, U+1f9bb, U+1f9be-1f9bf, U+1f9d0, U+1f9e0-1f9e1, U+1fa78-1fa79, U+1fac0-1fac2, U+1fae0-1fae7, U+1faf0-1faf6;
}

Answer 30 · 2022-05-16T17:57:07.000Z

Thanks @tomasdev. Any thoughts @jfkthame?

Answer 31 · 2022-05-24T17:23:13.000Z

@jfkthame what do you think of @Lorp's above suggestion?

Answer 32 · 2022-05-25T13:47:59.000Z

Might be feasible, I'm not sure offhand how complex the implementation issues would be.

However, I think there's another possible way forward: CSS Fonts defines a font-variant-emoji property which should allow the author to expressly ask for text-style or emoji-style presentation, overriding the defaults/heuristics that are currently happening.

I'm not sure any of the major browsers has implemented this property yet, but I think it's the solution here and we should just get it done.

(In the case of Firefox, it's https://bugzilla.mozilla.org/show_bug.cgi?id=1461589.)

Answer 33 · 2022-05-25T19:06:09.000Z

Screenshot of the Noto Emoji page in a Firefox build with added support for font-variant-emoji, and the text value added to the page (see the Inspector panel at the bottom):

Answer 34 · 2022-06-03T05:57:56.000Z

@jfkthame, font-variant-emoji seems like a promising workaround. The main drawback, as you pointed out above, is that it shifts responsibility onto website owners. Would it be possible to also pursue a more seamless solution?

Also, you explained earlier that, "When the U+FE0F selector is present, Firefox takes this as a strong request for an emoji-style presentation, and therefore looks for a font that supports one of the color-glyph technologies." I wonder if there's anything we can do to non-color emoji fonts (e.g. Noto Emoji) to indicate to Firefox that these are full-fledged emoji fonts... that might entail changes in the font binary and/or Firefox.

Answer 35 · 2023-07-04T09:39:50.000Z

as @behdad suggested above, we could add a dummy COLR table that for each pseudo-color glyph simply references its corresponding b/w glyph, but it feels like a hack to me.