Some emoji are line art in Ubuntu 20.04

[mcskwayrd]

Hi, I wanted to add a comment to this thread: Emoji are monochrome line art, or blank boxes; Brave 1.1.23 but it’s closed now, so apparently I have to open a new thread. I have tried everything described in that thread but the problem persists.

Description of the issue: Only a subset of emoji are rendered as color, the rest are monochrome line art.

How can this issue be reproduced?

1. Install Brave 1.9.80 on Ubuntu 20.04
2. Go to https://getemoji.com/
3. See that some emoji are color, but most are monochrome line art.

Expected result: All color emoji

Brave Version( check About Brave): 1.9.80

Additional Information:

Screenshot below.

Loading from a Private window had no effect.

Reinstalling noto fonts & restarting browser had no effect:
$ sudo apt install --reinstall fonts-noto-color-emoji

Linking from truetype directory to user font directory & restarting browser had no effect:
shopt -s dotglob; mkdir -p ~/.fonts/truetype/noto; ln -s /usr/share/fonts/truetype/noto/* ~/.fonts/truetype/noto

Re: @denshigomi’s instructions (in the prior thread) to “Inspect” an emoji and report what “Rendered Fonts”: I see…

Tinos—Local file(103 glyphs)
DejaVu Sans—Local file(66 glyphs)
Noto Color Emoji—Local file(46 glyphs)
Noto Sans Symbols2—Local file(3 glyphs)

Same problem exists in Chrome but not Firefox.

Screenshot:

[Mattches]

@mcskwayrd,
The first thing I would recommend is updating to the latest version of the browser – v1.20.103 at the time of writing this – then see if you get the same issue with emoji characters.

[mcskwayrd]

Ok, thanks! Interesting – I had no idea my version was out of date! It never showed up in the Snap Store as needing an update.

Well, having switched from Snap to the sources.list (“apt”) version, and just updated to Version 1.20.103 Chromium: 88.0.4324.152 (Official Build) (64-bit)…

…the problem goes away! Thank you for your help!

Feel free to close.

[mcskwayrd]

Interesting: there is one emoji still not covered: I have no idea what’s up with this one particular emoji, but I’m not going to worry about it. All the others are fine.

[Mattches]

@mcskwayrd,
That is strange and maybe clearing your cache or a simple relaunch might help. But I’m glad seemed to have done the trick for the rest!

[denshigomi]

@mcskwayrd
@Mattches

The bug was traced back to a glitch in fontconfig cache generation.
It was supposedly resolved, and sure enough, testing with a fresh install of Ubuntu 20.04.2 I no longer see this issue.

The remaining line art emoji on getemoji.com is the “Smiling Face”.
It’s still displayed as line art because the CSS on getemoji.com gives the “Liberation Serif” font priority over “Noto Color Emoji”.

“Liberation Serif” has a line art glyph for the “Smiling Face”, so it’s displayed. But “Liberation Serif” doesn’t have glyphs for the other emoji, so they’re rendered with “Noto Color Emoji”.

☺️ White Smiling Face Emoji

This can be verified by:

1. Right-click the line art emoji and click “Inspect”.
2. In the top-right pane that appears, uner the “Elements” tab, the “p style=“font-family: Segoe UI Emoji; font-size: 3.5em”” tag is highlighted. Double click it.
3. Change the font-family from “Segoe UI Emoji” to “Noto Color Emoji” and press enter.
4. The “Smiling Face” emoji will now be displayed in color.

Clearing the cache and relaunching won’t change it. That font selection is intentional, albeit undesirable in this case. If you go to another website, such as emojipedia, you’ll see the “Smiling Face” is rendered in color without editing the CSS.

Also, the missing emoji preceding “Smiling Face” (Smiling Face with Tear) is because neither “Liberation Serif” nor “Noto Color Emoji” have a glyph for it.

🥲 Smiling Face with Tear Emoji