In Safari, some Noto Emoji are blank and some are standard OS color emoji

philgyford commented 9 months ago

I use Noto Emoji on my site but noticed a few weeks ago (before, I think, I updated to macOS Sonoma) that in Safari some of the emoji that had previously been rendering correctly had now disappeared. And some others were rendering as the standard Apple emoji.

I ended up making a big test page of all(?) emoji, which should have them all rendering as bright green Noto Emoji.

For future reference, the HTML starts like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Emoji test</title>
    <link rel="preconnect" href="https://fonts.googleapis.com" />
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
    <link href="https://fonts.googleapis.com/css2?family=Noto+Emoji:wght@700&display=block" rel="stylesheet" />
    <style>
      p {
        font-family: "Noto Emoji", sans-serif;
        color: #0f0;
      }
    </style>
  </head>

and then each block of characters is a paragraph of emoji:

<p>🥇 🥈 🥉 🆎 🏧 🅰 ♒ ♈  ... </p>

In Chrome all the emoji appear as bright green Noto Emoji, as expected.

But in Safari (macOS and iOS), most of the 1 character emoji are blank. And lots of the 3+ character emoji appear as standard Apple emoji.

And in Firefox some of them appear as standard Apple emoji, which I assume is the same as #391.

Here's the left-hand side of the page in each of the browsers:

You can see similar results looking at the preview on fonts.google.com using Safari.

anthrotype commented 9 months ago

thanks for the thorough report, this is really helpful.

I wonder if the black & white Noto Emoji may be impacted by the same issue as the color emojis with sequences containing the U+FE0F variation selector: https://github.com/googlefonts/noto-emoji/issues/428 A workaround there was to strip that character from the font (e.g by removing it in the font's cmap table), maybe you could try that and see if that changes anything? (e.g. you could dump the font to XML using fonttools ttx, remove all entries related to the FE0F character in the cmap table, and re-compiling with ttx)

Though there may be something else going on here, because even single character emojis seem to appear blank here.

We will take a look on our end as well soon.

anthrotype commented 9 months ago

Hm, something must be going with macOS Sonoma specifically. Below are two screenshots of your testing page loaded in Safari, before and after upgrading to Sonoma. Notice the diff among the single-character emojis:

macOS Ventura 13.6.1

After upgrading to macOS Sonoma 14.0

philgyford commented 9 months ago

Ah interesting! I thought I'd noticed the issue before upgrading to Sonoma, but maybe before it was only the "coloured emoji" problem I'd noticed, and the "missing emoji" one was added after I upgraded.

FWIW, I'm currently working on generating a subset of the font to use on my site, as woff2 – because I only use a few emoji – and that seems to load just fine in Sonoma Safari. A few are still appearing as coloured regular emoji in Firefox though.

anthrotype commented 9 months ago

You can see similar results looking at the preview on fonts.google.com using Safari.

Actually the Google Fonts preview page works for me in Safari on macOS Sonoma, when I load the page by clicking on that link above (see screenshot below). I'm not sure why it doesn't work on your end..

anthrotype commented 9 months ago

FYI, I now updated to Sonoma 14.1 with Safari 17.1 and that also still shows blanks for those single-character emojis that should appear green on your testing page

philgyford commented 9 months ago

Actually the Google Fonts preview page works for me in Safari on macOS Sonoma

Huh, yes it works for me today! I have no idea why it looked how it did for me yesterday then.

drott commented 9 months ago

CC @reinhart1010

anthrotype commented 9 months ago

Huh, yes it works for me today! I have no idea why it looked how it did for me yesterday then.

well.. at least it works at the beginning, when you first load or reload the linked page

but as soon as you try to select the sample text below, you start seeing tofus! This is very weird. I made a video to show what I mean.

https://github.com/googlefonts/noto-emoji/assets/6939968/ae4ef0a0-f0ff-4277-a480-ab10e19a3780

wokalek commented 7 months ago

Have this issue with Sonoma 14.2

drott commented 7 months ago

Could this be https://bugs.webkit.org/show_bug.cgi?id=262223 - does this work in the Safari 17.2 and Safari TP > 183?

philgyford commented 7 months ago

I'm now using Safari on macOS "Version 17.2.1 (19617.1.17.11.12)" and the issue persists.

Julien-Marcou commented 4 months ago

I'm still having this issue on MacOS Sonoma 14.4.1 and Safari 17.4.1 with Noto Color Emoji.

Here is a video showing the bug: https://www.youtube.com/watch?v=bvYrsyx_2aE

As you can see, sometime all the emojis goes blank at once, and sometime you have to "interact" with them (like hovering them), to make them disappear.

I'm pretty sure these emojis were previously working on Safari (don't know if this issue is with Noto's font, MacOS or Safari).

Something that might help the debugging, I used Noto's font to make a demo about Unicode Emojis, on this demo, I added the feature to switch from your native OS Emoji font, to Noto Color Emoji font, and I can't reproduce the bug here, you can find the demo here: https://emoji.julien-marcou.fr/

On this demo, I had self-hosted Noto's font (source code of the demo available here: https://github.com/julien-marcou/unicode-emoji-picker-demo).

For the font I'm using the following CSS to switch between SBIX and COLRv1 fonts,

    @supports (-webkit-hyphens: none) {
      @font-face {
        font-family: 'NotoColorEmoji';
        font-style: normal;
        font-weight: 400;
        font-display: swap;
        src: url(/fonts/Noto-SBIX.woff2) format('woff2');
      }
    }
    @supports not (-webkit-hyphens: none) {
      @font-face {
        font-family: 'NotoColorEmoji';
        font-style: normal;
        font-weight: 400;
        font-display: swap;
        src: url(/fonts/Noto-COLRv1.woff2) format('woff2');
      }
    }

If I remove the @supports and only use the COLRv1 font, then I can reproduce the problem, so it looks like SBIX font is working as expected on Safari, but not COLRv1

anthrotype commented 4 months ago

thanks for the detailed report and the demo. what is that "Noto-SBIX.woff2"? How did you produce that one?

anthrotype commented 4 months ago

it looks like SBIX font is working as expected on Safari, but not COLRv1

that would be expected, because we know Apple platform does not currently support COLRv1, only sbix, OT-SVG and COLRv0

anthrotype commented 4 months ago

The web font used on fonts.google.com for NotoColorEmoji is a hybrid font that contains both COLRv1 table and SVG table. You can downloaded it from https://fonts.google.com/noto/specimen/Noto+Color+Emoji

When we serve the web font to browsers that we know do not support COLRv1 (e.g. Safari) we send them a subsetted copy of the font which only has SVG table and not the COLRv1 table.

Julien-Marcou commented 4 months ago

thanks for the detailed report and the demo. what is that "Noto-SBIX.woff2"? How did you produce that one?

I made that a long time ago, but yes, I think I had generated it from Noto Color Emoji's TTF font. (I don't remember the exact process 😅)

The web font used on fonts.google.com for NotoColorEmoji is a hybrid font that contains both COLRv1 table and SVG table. You can downloaded it from https://fonts.google.com/noto/specimen/Noto+Color+Emoji

When we serve the web font to browsers that we know do not support COLRv1 (e.g. Safari) we send them a subsetted copy of the font which only has SVG table and not the COLRv1 table.

I'm serving the font with: https://fonts.googleapis.com/css2?family=Noto+Color+Emoji&display=swap

On Google Chome, it loads:

On Safari, it loads:

So it would mean the issue is within the SVG font?

anthrotype commented 4 months ago

So it would mean the issue is within the SVG font?

presumably yes. Or in the Safari's implementation of OT-SVG support

anthrotype commented 4 months ago

On Safari, it loads: https://fonts.gstatic.com/s/notocoloremoji/v30/Yq6P-KqIXTD0t4D9z1ESnKM3-HpFabts6diysYTngZPnMC1MfLc.0.woff2

I decompressed and inspected the latter font with ttx, and it does in fact contain SVG table whereas the Chrome does not. I'm surprised to see that in addition to SVG table, the Safari font also contains the COLR table which is not supposed to be there since it'd be unused. I wonder if stripping it of that COLR table and leaving only the SVG one would make any difference as to the bug.

Julien-Marcou commented 4 months ago

what is that "Noto-SBIX.woff2"? How did you produce that one?

I think I used https://github.com/googlefonts/nanoemoji to generate the SBIX font

anniegreens commented 4 months ago

I have also been experiencing missing glyphs in Safari. For me, the particular combination of Safari + OS was key, as I only experienced it on iPadOS/iOS 17 + Safari AND MacOS Sonomoa + Safari 17, but NOT MacOS Ventura + Safari 17 NOR iOS 16.x.x.

I went down the rabbithole yesterday to attempt to solve this on a small site I put together within the last month before upgrading my devices (to Sonoma and iPadOS/iOS 17). What I discovered was that removing the bold variant styles and either defaulting or declaring directly a weight of 400 solved the missing glyph issue for me.

I really don't know who is to blame on this, something in the font itself, or Safari. I'd like to blame both equally 😆

I came across Phil's thread on this subject on StackOverflow before posting on Mastodon about this yesterday and he pointed to this thread so I decided to add my experience. The site Noto Emoji is used on that I had the issue as well as where I removed the weight variant styles is https://3x5.pics.

I went down this path as a solution after viewing the Google Fonts specimen page for Noto Emoji (https://fonts.google.com/noto/specimen/Noto+Emoji) in Safari 17 on MacOS Sonoma and seeing that the most consistent glyphs were only visible in the regular/400 weight.

Editing to note that I self-host the font, I am not using Google Fonts or Bunny Fonts to serve Noto Emoji.

Additional edit: I'd be curious to know from anyone who sees all weights on the Google Fonts specimen page whether they have Noto Emoji installed locally on their machines and if they inspect the page, can determine if the font is loading remotely or locally.

rsheeter commented 3 months ago

in addition to SVG table, the Safari font also contains the COLR table

This is a bug, will fix.

rsheeter commented 3 months ago

Confirmed we misunderstood the Safari 17 user agent. That should be fixed and observable by requesting https://fonts.googleapis.com/css2?family=Noto+Color+Emoji, in Safari at the bottom you should see

body {
  --google-font-color-notocoloremoji:otsvg;
}

Unfortunately I'm still seeing inconsistent rendering. For example, https://codepen.io/rs42/full/JjVzeyM renders for me but after a couple of selections or window resizes some or all the emoji vanish.

folsze commented 3 months ago

what is that "Noto-SBIX.woff2"? How did you produce that one?

I think I used https://github.com/googlefonts/nanoemoji to generate the SBIX font

I tried doing the same process by going into the nanoemoji repo and in the svg directory I ran: nanoemoji --color_format sbix *.svg

It produced a file like yours from the demo.

However: only some emojis in your demo or from my file, they still display the native styles in safari for some reason:

Mountain (⛰️): U+26F0 U+FE0F Snow-Capped Mountain (🏔️): U+1F3D4 U+FE0F Cityscape (🏙️): U+1F3D9 U+FE0F Comet (☄️): U+2604 U+FE0F Shamrock (☘️): U+2618 U+FE0F Studio Microphone (🎙️): U+1F399 U+FE0F Framed Picture (🖼️): U+1F5BC U+FE0F Shield (🛡️): U+1F6E1 U+FE0F Pick (⛏️): U+26CF U+FE0F Hammer and Pick (⚒️): U+2692 U+FE0F Hammer and Wrench (🛠️): U+1F6E0 U+FE0F Dagger (🗡️): U+1F5E1 U+FE0F Crossed Swords (⚔️): U+2694 U+FE0F Desert (🏜️): U+1F3DC U+FE0F Classical Building (🏛️): U+1F3DB U+FE0F

I checked and all those emojis exist in the noto color emoji svg folder, you can search by the unicode start, for mountain it's emoji_u26f0.svg

Is there any way to fix those missing emojis, does anyone know? Judging by that all the black tools are rendered natively, this could have a determinable cause? Since related emojis are all not displaying in noto color?

googlefonts / noto-emoji

In Safari, some Noto Emoji are blank and some are standard OS color emoji #438