Vscode: Cannot display emoji ✔, 🙋‍♂️

[yzhang-gh]

Steps to Reproduce:

1. Open a new file
2. Copy these two emoji ✔❌ to it
3. See this result

Expected

on Windows 10

[rebornix]

The style is decided by the browser and since we are using Chromium under the hood, it's Google's Emoji.

[rianadon]

This may not be how it really works, but from my understanding this is how Windows displays emoji as a fallback when no specific "emoji font" is used.

This can be fixed by adding 'Segoe UI Emoji' to the end of the editor.fontFamily setting so emojis fall back to the correct, colored font. Or you could use 'Segoe UI Symbol' instead to get monochrome emoji.

Thus, building off the default setting, Consolas, 'Courier New', monospace, 'Segoe UI Emoji' would give you colored emoji. This should really be the default. But for now you could change this yourself to make the emoji display correctly.

[yzhang-gh]

@rianadon many thanks!

[rianadon]

@alexandrudima I wouldn't call this an issue with something upstream since there is a solution to solve this in Electron/Chromium - add all the emoji fonts to the font stack. For example GitHub uses the emoji fonts for both macOS and Windows in their CSS (along with the native system fonts): -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol".

The fix to this would be to edit the default by appending Segoe UI Emoji and possibly the Apple emoji font too.

[yzhang-gh]

Another emoji:
🙋‍♂️ (man raising hand)
in vscode
expected (as shown on GitHub webpage)

with font settings Consolas, 'Microsoft Yahei', 'Segoe UI emoji', 'Segoe UI Symbol'
on Windows 10 Pro 1709

[rianadon]

I see this too. The issue goes away when I change the font to only 'Segoe UI Emoji', which likely handles the zero width joiner.

This probably isn't going to have an easy fix, as while putting the emoji font first fixes the problem, it doesn't allow for the customization of the text font (as the emoji font seems to have glyphs for text). One solution would be to do as GitHub does and enclose emoji inside a separate element with its own font-family, but doing so would require a change in Monaco's syntax highlighting.

[SylannBin]

When I paste this emoji: 👈, in any file in vscode (on ubuntu), I get this :

It's the same in the integrated terminal of vscode;

While it is properly displayed in my terminal (tilix).

[rianadon]

@SylannBin good find! Would you happen to know what font tilix is using?

Also what happens if you add 'Noto Color Emoji' to the start or end of your editor.fontFamily setting (with the single quotes)? It seems like this is the emoji font Ubuntu uses but I'm not completely sure.

[SylannBin]

@rianadon Adding the 'Noto Color Emoji' font family makes the above emoji properly displayed both in the editor and the integrated terminal.
But without surprise, it also affects all other characters.
For example, numbers and stars are showed in a peculiar white fashion:

However if I put the font at the end of the list, it works perfectly.

Apparently, the ability to print the emojis properly in tilix is not related to Tilix itlsef but to the version of GTK that is being used. Color emojis work in ubuntu 18.04 but not in 17.10, it appears it has been added with gtk 3.22. source I've searched a bit, in the gtk repo, it seems the feature was handled by cairo for several years already, and was fixed very recently in gtk, but this is quite obscure to me right now and I couldn't figure out which commits introduced the fix.

[rianadon]

Great to hear it works if you put the font at the end!
I've never seen an emoji font handle stars and numbers specially before though.

Also, I'm probably going to submit a PR soon to change the default font-family to include emoji. For my later reference (and anyone looking to make emoji work on their system), these defaults would be:

• Windows: Consolas, 'Courier New', monospace, 'Segoe UI Emoji'
• MacOS: Menlo, Monaco, 'Courier New', monospace, 'Apple Color Emoji'
• Linux: 'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback', 'Noto Color Emoji'

[NatoBoram]

I confirm that this worked for me on Ubuntu.

"editor.fontFamily": "'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback', 'Noto Color Emoji'"

[Yanpas]

Beetle :beetle: emoji used by java language server is not rendered on linux:

"editor.fontFamily": "'Twitter Color Emoji', 'Fira Code','Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback', 'Noto Color Emoji'"

Seems like there is color-emoji rendering problem on linux, kubuntu 18.04

[develleoper]

Also experiencing it on Windows 10, October update.
Especially difficult to get emoji fallbacks working in the integrated terminal (haven't found a fully working solution yet).

[Elaniobro]

add 🧪(test tube) emoji to the growing list.

[alexdima]

I have tested on browsers with https://microsoft.github.io/monaco-editor/

| app | result |
|---|---|
| VS Code Insiders (Chromium Version 69.0.3497.128) | |
| Chromium Version 69.0.3497.128 | |
| Chrome Stable Version 77.0.3865.90 | |
| Edge Dev Chromium Version 79.0.287.2 | |
| Chrome Canary Version 79.0.3936.0 | |

So, IMHO this is an upstream issue which will get resolved once we update to a newer Electron / Chromium version which contains this change... In the meantime, you can workaround on your machines via the editor.fontFamily

[polarathene]

While this is apparently solved(or will be with future Electron/VSCode release), thought I might suggest what might have been a cause.

✔️(✔️): https://emojipedia.org/heavy-check-mark/
❌(❌): https://emojipedia.org/cross-mark/

You can note the codepoints for both of these(defined after the image preview list from various vendors). ✔️ requires the Variation Selector VS16(FE0F) to switch to a colour presenation while the ❌ does not. If you were to inspect the codepoints used in the glyphs, you might just find that the ✔️ lacked the VS16 codepoint to indicate emoji presentation.

🙋‍♂️(🙋‍♂️): https://emojipedia.org/man-raising-hand/

This one does use a ZWJ(Zero-Width Joiner), but the 2nd emoji to compose it with ♂️(♂️), uses a VS16 as well, otherwise it presents itself as text.

🧪(🧪): https://emojipedia.org/test-tube/

This emoji was part of Unicode v11 in 2018. It's possible that the user who pointed this one out was using an emoji font that did not have the emoji, perhaps the latest version of the font did but the one they had did not. The user-friendly get noto website isn't always providing the latest versions of fonts(Noto Sans Mono is a good example of this, which has a github issue about ligature issues iirc, resolved on github but not updated on get noto). So depending where the font was sourced from and when, it could be that it simply did not have that emoji.

Chromium/Chrome also did not have complete COLR/CPAL font support across all platforms using Blink until around September 2018, which adds another possible cause(but less likely since @Elaniobro mentioned it in Aug 2019..). For what it's worth, it renders perfectly fine for me in Chrome and VSCode currently on Linux.

🐞(🐞): https://emojipedia.org/lady-beetle/

No clue about that one. Only one user seemed to be affected and they were happy to later notice it working(with a text variant) later.

It's been defined early on in Unicode and default presentation is colour/emoji afaik. They mention they use Ubuntu 18.04 at the time, which was when emoji support was just getting decent for Ubuntu iirc? I'm not sure what font was providing that glyph, it doesn't appear to be any in their font list(Maybe the twitter emoji one, assuming it had the black/white fallback).

---

I would say that they're all likely issues with font handling on the OS level(bad fallback/config), or user error(whomever defined the glyph/emoji and missed the VS16 where needed, or has an outdated font).

@alexandrudima I notice no issue with Chrome Version 77.0.3865.90 (Official Build) (64-bit) or VSCode (Chrome 69.0.3497.128) on Linux. Are you sure it's not the effect of something else?(there is no upstream commit to reference for Chrome provided related to this)

It could just be that you installed those at a time where something else on your system had changed and thus affected them? Similar to @Yanpas experience with 🐞, you can install some fonts and need to restart the apps or system for certain parts to properly take effect.

On Linux sometimes that may also require resetting the font cache(although that never seemed necessary for me and had no effect). I don't know how other OS handle it, but I wouldn't be surprised if uninstalling your stable chrome and reinstalling it showed similar results of fixing the problem?

To be clear, I've had rendering issues previously, but have been looking into the whys and how to fix them. Other fonts with emoji/symbols took priority as fallback over Noto Color Emoji for me in the browser(and anywhere else really), so I had to prevent that by tweaking some config files.

Technically rendering the ✔️ as black/white text style is correct if the VS16 was missing, so to not do so would be a regression/against spec. Likewise, 🙋‍♂️ decomposing to 🙋 + ♂️ (🙋 + ♂️) is correct for the same reasons, although some implementations might disregard that and render a minimally-qualified/unqualified sequence as 🙋‍♂️ since it was probably the intended result and there isn't an equivalent alternative, so long as the ZWJ was there to bind them.

In my current config, while I can paste 🙋‍♂️ as a single emoji just fine, right-click context menu, or pasting into ominbox or googles search field is pasting the decomposed version for me on my stable Chrome release as well as dev Version 79.0.3921.0 (Official Build) dev (64-bit), any newer version is not available on my system, your test didn't confirm if that is any different. Pasting it into the Monaco editor you linked works fine, but not omnibox.

[Lexicality]

I added , 'Segoe UI Emoji' to the end of all the Font Family settings and that fixed most of it, however emoji still don't render correctly in the intellisense popup for me.

Is there a secret font setting somewhere for this?

[xgqfrms]

macOS warning emoji render bug

⚠️

[engineervix]

I confirm that this worked for me on Ubuntu.

"editor.fontFamily": "'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback', 'Noto Color Emoji'"

Thanks! This also worked for me on Fedora 32