Noto Color Emoji broken on Chrome

[applecuckoo]

Describe the bug

EDIT: I've checked the .woff2 files being served using the Wakamai Fondue beta and confirmed that the font files only have an SVG table (OpenType-SVG), which only works on Safari/WebKit based browsers and Firefox (caniuse.com). Chrome has chosen not to implement OpenType-SVG in favour of COLRv1, and it's being supported by all major browsers at the moment except Safari, they had a negative stance on the proposal. See caniuse.com. So I think that the font should also be built with OpenType-SVG, until WebKit decides to implement COLRv1 into their system.

Steps to Reproduce

1. Download the served files from Fontsource
2. Upload the files to Wakamai Fondue and check under the 'Color' section.

Expected behavior

I expected the glyphs to be visible but they were not.

Version

4.5.2

OS

MacOS

Browser

Google Chrome

Additional context

This will also impact Edge and Opera users.

[ayuhito]

Can you confirm this is an issue with the NPM package? Technically if it is related to the font itself, that's probably an upstream issue. If it's related to the packaging of the font and its files, then we could dig more into it.

The first thing that pops into my mind is that this may be a user-agent problem. Google determines what files to serve depending on the user agent and perhaps the new COLRv1 features require a newer user agent. But I would expect a working fallback regardless...

[applecuckoo]

@ayuhito COLRv1 was created by Google themselves, the annoying bit is that building Noto Emoji takes a few hours (I'm even building a COLRv1+SVG version as I type this). Fortunately the compression is very quick.

[henrikvilhelmberglund]

Is there any way to solve this? Seems strange that a Google font wouldn't work in Chrome.

[applecuckoo]

I've put my COLRv1+SVG build in a GH repo, should just need to be subsetted and it should work. Again, a Wakamai Fondue check shows that the COLR table is nowhere to be found, so the table is probably not being packaged. The build is here. @rsheeter might be able to explain.

[ayuhito]

If there is a user-agent that fetches both tables in one file from GF, that would be a viable solution for this until all browsers support COLRv1 or SVGs.

The only trade-off is file sizes I'm assuming.

[rsheeter]

Can you clarify which font is broken on Chrome exactly? - https://fonts.google.com/noto/specimen/Noto+Color+Emoji is working fine for me.

Note that the Google Fonts css api will pick what color format to send based on the user agent's capabilities. You should get a COLRv1 font on modern Chrome, SVG on Safari, etc.

[applecuckoo]

@rsheeter Apologies, this is about the fontsource package, not the one offered through the GF API.

[rsheeter]

Oh I'm sorry, I completely missed what repo we're in and assumed it was in Noto Emoji :)

The copy in https://github.com/google/fonts/tree/main/ofl/notocoloremoji (upstream of Google Fonts) should have both SVG and COLR.

[ayuhito]

@rsheeter, is there a possibility we can acquire a user-agent that covers both tables? Possibly a fallback that occurs when the CSS API can't determine exactly what browser it might be?

We fetch fonts from the CSS API directly using these user agents.

Thanks!

[ayuhito]

Should be resolvable when #39's subsetter is implemented.

[satoren]

It does not appear to be working here either. https://fontsource.org/fonts/noto-color-emoji

[kazie]

I have been troubled by the color emojis not working in Chromium (but does in Firefox) too.

When the font-family gets set in chrome all emojis are blanked - while in Firefox they render as wanted for me.

What I am trying to do is having a small page with emojis showing Noto Color Emojis, since I want all kinds of devices to have the same experience (instead of Samsung phones and Apple phones showing different emojis).

Firefox - OK!

Chromium - No fonts?!