search

googlefonts / noto-emoji

Noto Emoji fonts
SIL Open Font License 1.1
3.74k stars 451 forks source link

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

Open Lorp opened 2 years ago

Lorp commented 2 years ago

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>

Screenshot 2022-05-04 at 15 05 48

anthrotype commented 2 years ago

maybe it's related to https://github.com/googlefonts/nanoemoji/issues/368#issuecomment-1012805866

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

/cc @behdad @rsheeter

Lorp commented 2 years ago

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.

Lorp commented 2 years ago

Safari 15.4

Screenshot 2022-05-04 at 16 20 56

Lorp commented 2 years ago

Chrome 101.0.4951.54

Screenshot 2022-05-04 at 16 21 08

Lorp commented 2 years ago

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

Lorp commented 2 years ago

Current Noto Emoji page in latest Firefox…

Screenshot 2022-05-04 at 16 38 56

behdad commented 2 years ago

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

anthrotype commented 2 years ago

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

behdad commented 2 years ago

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

behdad commented 2 years ago

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

behdad commented 2 years ago

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.

behdad commented 2 years ago

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

Adding a dummy color table...

behdad commented 2 years ago

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

jfkthame commented 2 years ago

@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.)

behdad commented 2 years ago

@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.

jfkthame commented 2 years ago

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.

behdad commented 2 years ago

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

behdad commented 2 years ago

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.

Lorp commented 2 years ago

Here is my test file @jfkthame

noto-emoji-test.html.zip

Lorp commented 2 years ago

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;

Screenshot 2022-05-04 at 20 14 18

Lorp commented 2 years ago

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

behdad commented 2 years ago

I see 241 FE0F's.

Lorp commented 2 years ago

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.

jfkthame commented 2 years ago

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.

Lorp commented 2 years ago

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

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

jfkthame commented 2 years ago

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.

jfkthame commented 2 years ago

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.

Lorp commented 2 years ago

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?

tomasdev commented 2 years ago

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;
}
Lorp commented 2 years ago

Thanks @tomasdev. Any thoughts @jfkthame?

nathan-williams commented 2 years ago

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

jfkthame commented 2 years ago

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.)

jfkthame commented 2 years ago

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):

image

nathan-williams commented 2 years ago

@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.

anthrotype commented 1 year ago

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.