Some Unicode characters (emojis) are b/w and others are colored

[weinand]

Testing: #91303 on Ubuntu 19.10 (running in Parallels)

• open VI in VS Code integrated terminal
• enter some emojis (e.g. 🥕carot U+1F955, 🍔hamburger U+1F354, 🥎softball: U+1F94E)

Observe:
in VS Code carot and hamburger are rendered in b/w whereas the softball is rendered in color.

If I enter the same characters in VI running in the terminal app all three emojis are rendered in color:

(left is VS Code, right is terminal app).

[stevencl]

Here's another one that shows up black and white 🗣 (U+1F5E3)

[Tyriar]

I always thought this was related to fonts, not sure we will be able to fix as I tell the canvas to draw the text and sometimes they get drawn as lofi.

[fmeyertoens]

The reason might be that some emojis are displayed in text style by default instead of emoji-style. The variation selector Unicode block (U+FE0F) can be added to those emojis to indicate that it should be displayed in emoji-style.
The gear emoji for instance should be inserted as U+2699, U+FE0F.
https://emojipedia.org/variation-selector-16/
https://en.wikipedia.org/wiki/Variation_Selectors_%28Unicode_block%29
(I somehow can't connect to unicode.org to find the definitive source)

[Tyriar]

@fmeyertoens sounds promising, created upstream issue xtermjs/xterm.js#2823

[fmeyertoens]

Might be related to #32840. It is originally about the editor but seems to be the same problem and people are also discussing the terminal behavior there.

[fmeyertoens]

After some research I am quite sure now that the variation selector is not the issue here because the emojis mentioned in the beginning

(🥕carot U+1F955, 🍔hamburger U+1F354, 🥎softball: U+1F94E)

shouldn't even have a text presentation and should be presented as emoji by default. So the emoji presentation selector (U+FE0F) has no effect on them. (See https://www.unicode.org/Public/13.0.0/ucd/emoji/emoji-data.txt and https://unicode.org/emoji/charts/emoji-style.html)
This does seem to be a font (fallback) issue. The default terminal font has the emoji characters (although in black&white) and so it doesn't fall back to the colored emoji font.
If VS Code and the terminal app use the same fonts then it could be that the terminal app prioritizes the emoji font for emoji characters.

Here's another one that shows up black and white 🗣 (U+1F5E3)

If the speaking head appears as on github (black&gray) then it is already the correct 'colored' emoji version of it.

[Tyriar]

For rendererType = canvas (the default) this is the font that's given to the canvas context to draw:

https://github.com/xtermjs/xterm.js/blob/f0c518a13471bbc4890905a076b292d2d0a9f63c/src/browser/renderer/BaseRenderLayer.ts#L390

Where this._optionsService.options.fontFamily is whatever is configured in vscode's terminal.integrated.fontFamily (uses editor.fontFamily if it's not set).

[Kedstar99]

Hello,

I know this probably isn't helpful as you probably have a better/simpler solution. I found this issue seems to occur on several Linux programs by default. I think it's rather an issue on linux's default font handling.

For example, below is an example image from running systemd-analyze security on default konsole, yakuake and terminator.

The problem in this case is that most of the monospace fonts I saw were only supporting up to Unicode 6.

This problem I think also occurs over here in VSCode, except unsupported emojis seem to get displayed as coloured emojis. Hence the mixture of b/w and colored in this case.

In theory this could be solved by switching to noto-color-emoji but unfortunately that seemed to also convert numeral characters into emojis as well.

My actual solution that seems to fix the problem in all of the terminals and vscode was to apply the font config here.

https://gist.github.com/IgnoredAmbience/7c99b6cf9a8b73c9312a71d1209d9bbb#gistcomment-2919833

I know this probably isn't the best solution and you probably would like a solution which works within vscode. It does seem to me that there is a lot of complexity involved with this binding and font config though. https://www.freedesktop.org/software/fontconfig/fontconfig-user.html

In theory, this should be a relatively simple adjustment in the snap versions at least. What do you think about that as maybe a short-term solution to this problem?

EDIT:
Here is the above solution being used to show the carrot, hamburger and softball.