How to render NotoColorEmoji on Linux #36
Comments
|
You need latest fontconfig, but also a patched version of cairo from this branch: Unfortunately no one has finished the patch to integrate into cairo yet :(. |
|
I installed fontconfig, patched cairo, and also freetype, graphite2, harfbuzz, zlib, libpng, libX11, libXrender, and pixman. |
|
What does this command say, does it find the font: $ fc-match "Noto Color Emoji" |
|
No: $ fc-match "Noto Color Emoji" |
|
Where / how did you install the new fontconfig? |
|
Got it from here: http://www.freedesktop.org/software/fontconfig/release/ $ fc-cache -V $ ls -l /usr/include/fontconfig/ $ ls -l /usr/bin/fc* It looks like maybe I have a conflicting old installation |
|
Yeah, new version probably went into /usr/local. The question is, why does it seem to be trying to read config files from /etc instead of /usr/local/etc |
|
Hello, I'm also looking into this. But wondering if its even worth it, when chrome does not even support color emoji anyway. |
What do you mean? Chrome on Linux certainly supports Noto Color Emoji just fine for me. You might need a newer fontconfig. |
|
Thank you for getting back to me. I compiled cairo patch from your repo and fontconfig 2.11.94 from http://www.freedesktop.org/software/fontconfig/release/. vooze@vooze-vb: Still unable to install the font. Either manually (press Install in font viewer on ubuntu 16.04 daily) or putting it in .fonts dir. |
|
Also just tested. Microsoft color emojis (tested with those, because noto wont install) works in Firefox but is still black/white in Chrome in Linux, like in Windows. |
|
Try deleting /etc/fonts/conf.d/70-no-bitmaps.conf that I believe Ubuntu puts in there. Though, that shouldn't be needed with latest fontconfig, hence, why I don't know what your problem is. |
|
@behdad I've compiled the latest fontconfig from git as well as the Thanks! (Apologies for the colors in the screenshot. Not sure why taking a screenshot messes with the colors of the emojis)
|
|
Thats dejavu sans. |
|
We don't have a good solution to that yet, but one way would be to add this snippet to your ~/.fonts.conf: |
|
@behdad Thanks for the reply! I gave that a try (put it in |
|
Humm, I don't know. |
|
Even with an old version of fontconfig included in Ubuntu Trusty (but with a recent FreeType to support color bitmap fonts that I installed locally), putting the following in your local fontconfig configuration file (e.g. ~/.fonts.conf ) would work (at least, it works well for me with Chrome). The 2nd part below does, only to chrome, what Behdad's snippet (2 days ago) does for all programs so that they should be equivalent as long as chrome is concerned. |
|
Jungshik: have you got it all working on Ubuntu? If so you you possible post a small "guide"? I Would be truly grateful! |
|
Wow autocorrect screwed that up. Let me try again: Jungshik: Have you got it all working on Ubuntu? If so would you possible post a small "guide"? I would be truly grateful! I have tried and failed. :-\ |
|
Hi! I'm interested if there is upstream bug opened for this. Also, is future work on those patches planned? Thanks! |
|
I subscribed to this issue a while ago hoping for a better fontconfig solution myself. I researched this font/glyph priority issue for far too long and I ended up settling on replacing DejaVu with Bitstream Vera for my emoji font's suggested fontconfig. Bitstream Vera is the source of the DejaVu glyphs and doesn't have any of the conflicting emoji characters. The same process can be adjusted to work for Noto Color Emoji. The only other solution AFAIK is subsetting DejaVu or Noto. Long term, DejaVu or Noto Sans/Serif/etc probably should use the solution Apple & Microsoft went with, as I understand, and not put any emoji (even text-default emoji) characters anywhere except emoji specific fonts. A different solution would be great though. Edit: Difference vs the @jungshik method is my method is for a system-wide replacement. It may not be applicable for Noto Color Emoji since it doesn't contain regular glyphs. |
|
@vooze : Do what I wrote in #36 (comment)
|
|
@jungshik, do you have this font working without patched Cairo (you don't mention it in your guide)? |
|
@abbradar What I wrote is Chrome-specific (pngname matching 'chrome' in fontconfig) and Chrome does not use Cairo. |
|
@jungshik Ah, I see! Thanks. |
|
Any progress on this one? What exactly needs to be done to make color Emojis show up everywhere on Linux (not just in the browser)? Today Microsoft presented their brand new Emojis for Windows 10, see: Yet on Linux desktop operating systems we still don't have full color Emoji support. Why is that? |
|
Ugh. I wish emoji die so we don't get so much "any progress on this" messages. No progress on this. Because apparently no one in the world (including myself) has time to finish my patch. Period. Go bug your Linux distro please. |
|
@jbicha The reason was the disabled hinting. Changing it to slight brought colour emojis to life. Why do bitmaps depend on hinting? |
That's a bug. File a bug at bugs.freedesktop.org against cairo graphics library. |
|
I see here that things should work out of the box on Debian Buster... is there a backports setup or PPA with all the needed updated components that will work on systems based on Ubuntu 16.04? I've gotten things working in Arch but would like it to also work elsewhere. I guess along those same lines, can I get a list of the minimum versions I should look for? I've gathered I need cairo, fontconfig, and the noto fonts but am not sure which versions and if the needed config is bundled or if I need to verify it exists. Thanks to all who've put work into this and have posted comments about their experiments. Both are greatly appreciated. |
|
|
This is what I see in Firefox 58.0.2 on Arch Linux: I use Noto fonts in Firefox. |
|
@simonbcn your screenshot is mostly displaying 2 fonts, EmojiOne and Symbola. I can't tell if any of the glyphs shown is from NotoEmoji. |
|
AFAICS, the getemoji.com site is rather Windows-centric: it applies "font-family: Segoe UI Emoji" (which is only likely to be available on Windows) to the emoji content, and doesn't specify any alternative fonts for other platforms. So you're likely to be seeing the result of default font fallback. Explicitly including Noto Color Emoji in the font-family list would probably change the result; or for Firefox 59 and later, the patch that landed in bug 1032671 may help to improve the fallback behavior. |
|
I've uninstalled Symbola, NotoEmoji, DejaVu and I have installed EmojiOne only. Now it works well in all webs: https://www.emojicopy.com/ http://getemoji.com/ https://es.piliapp.com/facebook-symbols/ ... |
|
I can confirm @ugjka solution worked in my case for Polybar (polybar/polybar#905) |
|
A few notes: NotoColorEmoji now is packaged in Debian Buster and Sid https://packages.debian.org/sid/fonts-noto-color-emoji I think they are just using the binary from the Releases page of this repo instead of building it from source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848198#64 It should be noted that fonttools, which is required to build the font from source, has been switched over to the MIT license six months ago, so this font should now be able to be built from source with all free software build tools: fonttools/fonttools@b990a01 |
|
The Noto Color Emoji package in Debian is built from source using fonttools and zopfli. |
|
I followed @wpaulino method, and now I have huge white spaces between words in Chromium in arch. But somehow this only occurs in github, not other website. Also, numbers are rendered incorrectly into emoji. Any ideas? |
|
@ugjka some how it messes up my chromium rendering |
|
works fine here on arch kde |
The @wpaulino method from the comment above is a bit too coarse in my opinion: It makes Noto Color Emoji your default system font. Github is using the system font to display text. This makes spaces and numbers render as emoji, and the actual sans-serif text on github is then rendered using fallback. Release versions of Chrome ship their own versions of FontConfig and FreeType, which should work with Noto Color Emoji, however, we still need to fix issue 767754 to address more precise selection of the emoji font. |
|
@Moelf Don't use github as your way to test font configuration. It replaces emojis with images under some conditions, one of them being your user-agent matchthing |
|
@Moelf |
|
I have the same issue on terminal. It's working in Chrome: Also Firefox: But it's very huge on terminal: Here is my config: <?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="scan">
<test name="family">
<string>Noto Color Emoji</string>
</test>
<edit name="scalable" mode="assign">
<bool>true</bool>
</edit>
</match>
<match>
<test name="family"><string>sans-serif</string></test>
<edit name="family" mode="prepend" binding="weak">
<string>Noto Color Emoji</string>
</edit>
</match>
<match>
<test name="family"><string>serif</string></test>
<edit name="family" mode="prepend" binding="weak">
<string>Noto Color Emoji</string>
</edit>
</match>
<match>
<test name="family"><string>Apple Color Emoji</string></test>
<edit name="family" mode="prepend" binding="strong">
<string>Noto Color Emoji</string>
</edit>
</match>
</fontconfig>And terminal output: Any one can help? |
|
You could add at the end of the |
|
Can someone please add the tl;dr instructions to the Arch Linux wiki? There are like 10+ different fontconfig settings floating around on the internet and most of them don't work... |
|
Would anyone know why Noto Color Emoji would render well in Konsole but not in st or urxvt? I've been digging through configs trying to figure this out for a few days and have come up with nothing |
Prior to this CL, Chrome on desktop Linux often inconsistently used contour fonts (e.g., DejaVu Sans and Noto Sans Symbols2) for some emojis, even when a dedicated emoji font (e.g., Noto Color Emoji) is available and used for all other emojis. In order to force the color emoji font to be used always, hacks [1] have been mentioned in online forums that prepend the color emoji font to the list of system fonts in fonts.conf, which can have highly deletorious effects on other applications (like normal numerals becoming their emoji versions). The ISO locale code "und-Zsye" [2] is one of the ways of informing fontconfig (as of version 2.12.5) that color emoji fonts should be preferred, along with the special font family "emoji" [3]. fontconfig also has default configurations that automatically map the locale and the "emoji" family to any available color emoji font. By explicitly setting the locale to "und-Zsye", this CL provides the desired out-of-the-box experience to desktop Linux users. While we could also specify the "emoji" font family either instead of or in addition to the locale, doing so requires more plumbing in the code and may be done in the future. [1]: googlefonts/noto-emoji#36 [2]: https://unicode.org/reports/tr51/#Emoji_Script [3]: https://bugs.freedesktop.org/show_bug.cgi?id=94551 Bug: 767754 Change-Id: Ie8019cc0540a177c816c8131ca7c6a504952aa09 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2207627 Commit-Queue: Timothy Gu <timothygu@chromium.org> Reviewed-by: Dominik Röttsches <drott@chromium.org> Cr-Commit-Position: refs/heads/master@{#772414}
Prior to this CL, Chrome on desktop Linux often inconsistently used contour fonts (e.g., DejaVu Sans and Noto Sans Symbols2) for some emojis, even when a dedicated emoji font (e.g., Noto Color Emoji) is available and used for all other emojis. In order to force the color emoji font to be used always, hacks [1] have been mentioned in online forums that prepend the color emoji font to the list of system fonts in fonts.conf, which can have highly deletorious effects on other applications (like normal numerals becoming their emoji versions). The ISO locale code "und-Zsye" [2] is one of the ways of informing fontconfig (as of version 2.12.5) that color emoji fonts should be preferred, along with the special font family "emoji" [3]. fontconfig also has default configurations that automatically map the locale and the "emoji" family to any available color emoji font. By explicitly setting the locale to "und-Zsye", this CL provides the desired out-of-the-box experience to desktop Linux users. While we could also specify the "emoji" font family either instead of or in addition to the locale, doing so requires more plumbing in the code and may be done in the future. [1]: googlefonts/noto-emoji#36 [2]: https://unicode.org/reports/tr51/#Emoji_Script [3]: https://bugs.freedesktop.org/show_bug.cgi?id=94551 Bug: 767754 Change-Id: Ie8019cc0540a177c816c8131ca7c6a504952aa09 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2207627 Commit-Queue: Timothy Gu <timothygu@chromium.org> Reviewed-by: Dominik Röttsches <drott@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#772414} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 671511b00e2d6c374a3079c1c379d2d0dfad32fe
|
Since some people (in forums and other places) are still struggling getting this font to work properly, here's the necessary steps. Problem 1: Noto Color Emoji renders with inverted colors -> Bug in your toolkit/lib. Should be fixed everywhere by now, go upgrade. Problem 2: Emoji are much larger than surrounding text -> Noto is a bitmap font with 64px tall glyphs. To allow them to shrink, scaling must be allowed in fontconfig. Either enable globally (look for Problem 3: Getting emojis from other/black-and-white fonts mixed in -> Your regular fontset (usually DejaVu) has some emoji glyphs that are being preferred. Tell fontconfig to prepend Noto: Problem 4: Random stuff, not just emoji get replaced with Noto -> Do you have an older Noto (non-color) Emoji installed? Get rid of it. Problem 5: Some apps still render broken fonts? Likely the app is broken. Ripcord is known to be problematic, see here |
and others
I've built the font and uploaded it here but my system is unable to read it.
What do I need to be able to use it?
The text was updated successfully, but these errors were encountered: