Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
philgyford opened this issue Nov 5, 2023 · 23 comments
Assignees
Labels

Comments

@philgyford
Copy link

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:

emoji_screenshots_33

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

Screenshot 2023-11-05 at 17 58 46

@anthrotype
Copy link
Member

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: #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
Copy link
Member

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

Screenshot 2023-11-06 at 10 49 03 (2)

After upgrading to macOS Sonoma 14.0

Screenshot 2023-11-06 at 11 15 37 (2)

@philgyford
Copy link
Author

philgyford commented Nov 6, 2023

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
Copy link
Member

anthrotype commented Nov 6, 2023

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

Screenshot 2023-11-06 at 11 46 16

@anthrotype
Copy link
Member

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
Copy link
Author

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
Copy link

drott commented Nov 6, 2023

CC @reinhart1010

@anthrotype
Copy link
Member

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.

Screen.Recording.2023-11-07.at.10.49.06.mov

@wokalek
Copy link

wokalek commented Dec 23, 2023

Have this issue with Sonoma 14.2

@drott
Copy link

drott commented Jan 3, 2024

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
Copy link
Author

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

@Julien-Marcou
Copy link

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
Copy link
Member

anthrotype commented Apr 17, 2024

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

@anthrotype
Copy link
Member

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
Copy link
Member

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
Copy link

Julien-Marcou commented Apr 17, 2024

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
Copy link
Member

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

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

@anthrotype
Copy link
Member

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
Copy link

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
Copy link

anniegreens commented Apr 19, 2024

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 rsheeter self-assigned this Apr 19, 2024
@rsheeter rsheeter added the bug label Apr 19, 2024
@rsheeter
Copy link
Contributor

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

This is a bug, will fix.

@rsheeter
Copy link
Contributor

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
Copy link

folsze commented May 12, 2024

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?

akb2 pushed a commit to akb2/noto-emoji that referenced this issue Sep 17, 2024
akb2 pushed a commit to akb2/noto-emoji that referenced this issue Sep 17, 2024
akb2 added a commit to akb2/noto-emoji that referenced this issue Sep 17, 2024
akb2 added a commit to akb2/noto-emoji that referenced this issue Sep 17, 2024
akb2 added a commit to akb2/noto-emoji that referenced this issue Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants