GeezerVison is showing github.com — Cannot render Apple Color Emoji in plots · Issue #12830 · matplotlib/matplotlib
Cannot render Apple Color Emoji in plots #12830Description
Bug report
In both Jupyter Notebook and Terminal, I cannot display emojis using the Apple Color Emoji font.
If I attempt to set fontname='Apple Color Emoji' matplotlib won't find the font, and falls back to the default font DejaVu Sans, which renders the image below.

If I try to load the font using font_manager.FontProperties, it throws an error: RuntimeError: In FT2Font: Could not set the fontsize.
Code for reproduction
import matplotlib.pyplot as plt
from matplotlib.font_manager import FontProperties
import numpy as np
prop = FontProperties(fname='/System/Library/Fonts/Apple Color Emoji.ttc')
freqs = [301, 96, 53, 81, 42]
labels = ['😊', '😱', '😂', '😄', '😛']
plt.figure(figsize=(12,8))
p1 = plt.bar(np.arange(len(labels)), freqs, 0.8, color="lightblue")
new_ylim = plt.ylim()[1]+30
plt.ylim(0, new_ylim)
# Make labels
for rect1, label in zip(p1, labels):
height = rect1.get_height()
plt.annotate(
label,
(rect1.get_x() + rect1.get_width()/2, height+5),
ha="center",
va="bottom",
#fontsize='30',
#fontname='Apple Color Emoji'
fontproperties = prop
)
plt.show()
Matplotlib version
- Operating system: MacOS Sierra 10.12.6
- Matplotlib version: 2.2.3
- Matplotlib backend: MacOSX and module://ipykernel.pylab.backend_inline
- Python version: Python 3.7.0
- Jupyter version (if applicable): 5.6.0
Related StackOverflow question. Reacted by Samuel Ainsworth and Toma ActivityImportanceOfBeingErnest commented on Nov 18, 2018 Similar problem: #4492
It seems this somehow worked by coincidence. But as commented on the SO post already, one would start by using the codes that are reported to work in #4492 and see where the difference is. anntzer commented on Nov 18, 2018 Actually that's a limitation of FT2Font.
I couldn't get my hands on Apple Color Emoji.ttc, but at least with Apple Color Emoji.ttf, things work if you use the mplcairo backend (https://github.com/anntzer/mplcairo), and I have no reason to believe that the ttc version would be different.
(The fact that setting the fontname instead of the path doesn't work for ttc files "should" be fixed by #9787, which "just" waits for a second review...) Reacted by Brienna Herold and Ruben Vereecken Reacted by Anya Bataeva brienna commented on Nov 18, 2018 According to #3135, ttc font support is limited as well. It would be nice if we have #9787...
@anntzer, I can't seem to build the wheels with mplcairo, using OS X. anntzer commented on Nov 18, 2018 brienna commented on Nov 19, 2018 When running clang build-osx-wheel.sh:
ld: warning: ignoring file build-osx-wheel.sh, file was built for unsupported file format ( 0x23 0x21 0x2F 0x62 0x69 0x6E 0x2F 0x62 0x61 0x73 0x68 0x0A 0x0A 0x23 0x20 0x42 ) which is not the architecture being linked (x86_64): build-osx-wheel.sh
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
anntzer commented on Nov 19, 2018 You don't want to run clang build-osx-wheel.sh, but just ./build-osx-wheel.sh (or even python setup.py bdist_wheel should be good enough (modulo dependencies) given that you just want to use the wheel locally). brienna commented on Nov 19, 2018 Thanks! The installation got a bit further this time, but ends with
src/_feature_tests.cpp:3:4: error: "A compiler supporting C++17 is required."
#error "A compiler supporting C++17 is required."
^
1 error generated.
error: command 'x86_64-apple-darwin13.4.0-clang' failed with exit status 1
I had installed clang via homebrew llvm as instructed in the Build section. anntzer commented on Nov 19, 2018 Well, that's what the error message says: your version of clang is too old. You can install a more recent version with homebrew or conda, then make sure it is active. brienna commented on Nov 19, 2018 Two things were important: To git clone the repo instead of downloading it, and to make sure that llvm's compiler variables were set correctly before installing:
echo 'export PATH="/usr/local/opt/llvm/bin:$PATH"' >> ~/.bash_profile
source ~/.bash_profile
export LDFLAGS="-L/usr/local/opt/llvm/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include"
export CC='/usr/local/opt/llvm/bin/clang'
export CXX='/usr/local/opt/llvm/bin/clang++'
tools/build-osx-wheel.sh
I moved build > lib.macosx-10.9-x86_64-3.7 > mplcairo to my repo where I had my code, and in Jupyter Notebook added:
import mplcairo
matplotlib.use("module://mplcairo.macosx")
print(matplotlib.get_backend())
Τhen I ran my code again and got

So much better! But monochrome? 😩😤 And other colors are off too. anntzer commented on Nov 19, 2018 Not sure what's happening with monochrome but...
- You need to install the wheel (that's in the dist directory) with
pip install /path/to/mplcairo-etc-etc.whl.
- Making things work in the notebook is a bit hackish (does it work better if you run a standalone script outside of the notebook?), however (having installed the wheel as above) things should work in the notebook if you set the
MPLCAIRO_PATCH_AGG environment variable to 1 before starting the jupyter server (e.g. MPLCAIRO_PATCH_AGG=1 jupyter notebook), as documented in https://github.com/anntzer/mplcairo#use.
Also, can you check your version of cairo? (mplcairo._mplcairo.__cairo_version__) It needs to be at least 1.15.8 for color emoji support (https://www.phoronix.com/scan.php?page=news_item&px=Cairo-1.15.8-Colored-Emoji). And let's also get the freetype version (mplcairo._mplcairo.__freetype_version__) while we're at it. brienna commented on Nov 19, 2018 Installed the wheel so I can import mplcairo systemwide.
Ran a standalone script outside the notebook by importing mplcairo (owing to your MPLCAIRO_PATCH_AGG and MacOSX backend incompatibility notes), as well as running in Jupyter using MPLCAIRO_PATCH_AGG=1 jupyter notebook. Both approaches yield the same monochromatic emojis.
I'm using cairo 1.18.0. anntzer commented on Nov 19, 2018
I'm using cairo 1.18.0.
That's the pycairo version (I know, it's confusing :/).
The cairo version is accessible as import mplcairo._mplcairo; print(mplcairo._mplcairo.__cairo_version__); can you check that, and the freetype version too (as above)?
Also, perhaps try some other color emoji font, e.g. Noto Color Emoji (https://github.com/googlei18n/noto-emoji/tree/master/fonts)?
Still not sure why it's failing for you... anntzer commented on Nov 8, 2024 QuLogic commented on Feb 27, 2025 I'm going to try and see if I can get this in with the font shaping work. anntzer commented on Feb 27, 2025 @QuLogic I saw you mentioned in this week's meeting notes that raqm is working "except font fallback". This is very exciting :-)
Regarding font fallback, it looks like the "proper" approach (as described by the author of raqm...) is the one described at https://tex.stackexchange.com/questions/520034/fallback-for-harfbuzz-fonts#comment1315285_520048, which I have tried to implement for mplcairo (raqm's API should be enough to implement it, by relying on raqm_set_freetype_face_range) but is actually a bit tedious to do... QuLogic commented on Feb 27, 2025 Yep, that is in fact what I'm following (I think you had the link in mplcairo), but running into some issues with it not actually doing it. I think there may be some cache interfering, so I'm going to try to layout from scratch for every fallback, but that is as you say a bit tedious. QuLogic commented on Jun 12, 2025 With the FT2Image removal and FreeType 2.13, I am able to render some colour emoji:

This is only COLRv0, and I believe some modern fonts are using SVG instead. I also discovered some bugs in the FreeType API we're using, so there may need to be some additional workarounds/patches in place. That will require a bit more work, but will probably happen after all the other stuff is merged. anntzer commented on Jun 12, 2025 I'd be curious to hear about the bugs (even if very summarily). Also, support for SVG fonts looks awkward as freetype requires you to bring your own SVG(-subset) renderer; from a quick look I just realized that cairo, for example, implements its own. Do you have a plan here?
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|