Open Lorp opened 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
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.
Safari 15.4
Chrome 101.0.4951.54
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
Current Noto Emoji page in latest Firefoxβ¦
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
I guess this should be filed as FireFox bug. is there something to be done from the font side to fix/work around this?
Those seem to have
Extended_Pictographic
property in Unicode: https://unicode.org/Public/UNIDATA/emoji/emoji-data.txtNo idea what that property means.
Humm. That's not it. Most of the emoji should be in there...
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.
is there something to be done from the font side to fix/work around this?
Adding a dummy color table...
@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.)
@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.
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.
You're right. My bad. I spot-checked a few (telephone vs white telephone, hot pepper vs eggplant, etc...)
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.
Here is my test file @jfkthame
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β¦
βΊ βΊ️ ☺ ☺️
So are these malfunctioning because they are based on pre-Emoji BMP Unicodes, with the FE0F suffix intended to trigger Emojiness?
I see 241 FE0F's.
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.
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.
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.
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.
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.
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?
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;
}
Thanks @tomasdev. Any thoughts @jfkthame?
@jfkthame what do you think of @Lorp's above suggestion?
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.)
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):
@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.
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.
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.