Open philgyford opened 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.
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
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.
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..
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
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.
CC @reinhart1010
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
Have this issue with Sonoma 14.2
Could this be https://bugs.webkit.org/show_bug.cgi?id=262223 - does this work in the Safari 17.2 and Safari TP > 183?
I'm now using Safari on macOS "Version 17.2.1 (19617.1.17.11.12)" and the issue persists.
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
thanks for the detailed report and the demo. what is that "Noto-SBIX.woff2"? How did you produce that one?
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
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.
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?
So it would mean the issue is within the SVG font?
presumably yes. Or in the Safari's implementation of OT-SVG support
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.
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 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.
in addition to SVG table, the Safari font also contains the COLR table
This is a bug, will fix.
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.
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?
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:
and then each block of characters is a paragraph of emoji:
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.