Twemoji Color Emoji SVGinOT: color emoji that Firefox renders and Chrome ignores

The problem it solves is a font fallback gap, not a missing glyph set

Most Linux distributions ship DejaVu, which carries black and white outline glyphs for a wide range of symbol and emoji code points. Any emoji font you install gets overridden by those DejaVu characters, which is why dropping a color emoji font into a home directory often changes nothing you can see. The README names this directly: DejaVu "includes a wide range of symbols which override the Twitter Color Emoji characters."

A previous solution was to make Twitter Color Emoji the default system font, but it "causes a number of issues." The approach here is narrower. Install the emoji font for the user or the system, and pair it with a default text font that does not claim emoji code points. The suggested pairing is Bitstream Vera, which is the source of the glyphs DejaVu was derived from, so the text rendering difference is small enough that most people will not notice it.

This is a font swap aimed at people who want the Twemoji artwork and its family of modifiers, zero width joiner sequences and country flags, rather than whatever the operating system ships. It is for Linux, macOS and Windows desktops where browser rendering is the deciding factor.

How SVGinOT works and why Chrome says no

SVG in OpenType is an Adobe and Mozilla standard that lets a font embed complete SVG documents as glyphs. Because the artwork is vector markup inside the font file rather than a bitmap table, a renderer can draw it at any size and, in principle, animate it. The README links the W3C SVGinOT proposal and the OpenType SVG table specification.

The catch is renderer support. The README states the font "will currently only show color emoji in Firefox, Thunderbird, and Photoshop CC 2017+", and adds that this "is not a limitation of the font, but of the operating systems and applications," pointing at a Chromium bug entry for why Chrome falls back. Regular black and white outline emoji are included in the font so that applications which ignore the SVG table still show a recognizable emoji rather than a blank box.

That design decision is what makes the font safe to install system-wide. The worst case in an unsupported application is monochrome rendering, not missing characters.

Installing on Linux without root, then fixing the default font

The releases page hosts a tarball per version. The user-level path downloads, unpacks and runs the bundled installer:

# 1. Download the latest version
wget https://github.com/13rac1/twemoji-color-font/releases/download/v15.1.0/TwitterColorEmoji-SVGinOT-Linux-15.1.0.tar.gz
# 2. Uncompress the file
tar zxf TwitterColorEmoji-SVGinOT-Linux-15.1.0.tar.gz
# 3. Run the installer
cd TwitterColorEmoji-SVGinOT-Linux-15.1.0
./install.sh

Installing the font alone does not defeat DejaVu, so the text default has to change too. The README suggests Noto and Roboto as alternatives that "conflict far less than DejaVu", and names the practical sticking points as the 0x2639 and 0x263a characters.

Distribution channels exist for people who would rather not manage tarballs. Ubuntu users can add the Launchpad PPA and install the package:

sudo apt-add-repository ppa:eosrei/fonts
sudo apt-get update
sudo apt-get install fonts-twemoji-svginot

Arch has an AUR package named ttf-twemoji-color. Gentoo users need layman with Portage's USE="git" enabled, then add the overlay and emerge the font:

# Install layman using Portage with USE="git" enabled, the default.
emerge layman
# Add the repo.
layman -a jorgicio
# Install the package.
emerge twemoji-color-font

macOS and Windows each need a different trick to win the font match

On macOS the releases page carries two archives. The regular one installs like any font and can be selected by name, but the system keeps choosing Apple Color Emoji for emoji characters. The MacOS-specific build is described as "a hack" that replaces Apple Color Emoji by reusing the same internal name; install it and accept the warning Font Book shows. Homebrew distributes it as a cask:

# Tap the brew tap homebrew/cask-fonts keg (caskroom/fonts keg were moved into this).
brew tap homebrew/cask-fonts
# Install the font using brew
brew install --cask font-twitter-color-emoji

Windows has the same two-way split, plus a specificity problem. Windows 7, 8 and 10 draw emoji from both Segoe UI Symbol and Segoe UI Emoji, so both must be replaced while keeping the existing symbol characters from Segoe UI Symbol. The Win package ships an install script that generates the fonts and installs them. Package managers handle the same job:

choco install twemoji

# First, add the `nerd-fonts` bucket
scoop bucket add nerd-fonts
# Then you can install the font using Scoop
scoop install twemoji-color-font

On both platforms the README repeats the caveat: only Firefox renders the color version, and Safari and Chrome use the fallback.

Two documented failure modes you will probably hit on Linux

The first is alignment in monospace contexts. Emoji inside fixed width text cause incorrect character alignment, because Pango and GTK applications take whitespace widths from the most recently selected fallback font. In a terminal or a code listing this shows up as drifting columns, and no option in this font corrects it, since the problem sits in the fallback selection logic rather than in the emoji glyph.

The second is font family matching in Linux Firefox, tracked as issue 31 with a linked Bugzilla report. The workaround is a preference change: open about:config and set gfx.font_rendering.fontconfig.fontlist.enabled to false. The README flags the cost of that workaround directly, noting it may cause crashes in Firefox versions before 48.

A quieter issue is glyph coverage. The release tags track Unicode versions, and the newest listed release is v15.1.0 for Unicode 15.1. Anything added in a later Unicode release has no glyph until a new build exists.

Building from source needs Inkscape, and the Makefile says so up front

The repository is a Makefile project. The build produces a regular font, a MacOS font, a Linux package, a Debian package and a Windows package, all named from the VERSION and FONT_PREFIX variables:

VERSION := 15.1.0
FONT_PREFIX := TwitterColorEmoji-SVGinOT
DEB_PACKAGE := fonts-twemoji-svginot

Inkscape is a hard dependency, not a soft one. The Makefile calls which inkscape at parse time and errors out with "No inkscape in PATH, it is required for fallback b/w variant." It then probes the Inkscape version to pick export flags, using --without-gui --export-png for releases before 1.0 and --export-filename for 1.0 and later, which is what makes the black and white fallback glyphs possible.

Assets live in three directories. assets/twemoji-svg holds the upstream artwork, assets/svg is described in the Makefile as currently empty and reserved for additions, and assets/svg-bw holds black and white only glyphs that bypass processing. Scratch output goes to build/stage, build/svg-bw and build/svg-color, and TMP defaults to /dev/shm so intermediate work stays out of disk writes.

The README documents no rollback procedure for a build, and the LICENSE files split into LICENSE-CC-BY.txt, LICENSE-MIT.txt and LICENSE.md because the artwork and the build tooling carry separate terms. Read LICENSE.md before redistributing a build.

How this differs from Noto Color Emoji

This project uses SVGinOT, which embeds SVG artwork in the font and can, in principle, support animation, but is currently rendered in color only by Firefox, Thunderbird and Photoshop CC 2017+.

For users who prefer the Twemoji artwork and primarily use Firefox, the project's narrower SVGinOT renderer coverage may be an acceptable trade-off.

Editorial conclusion

Adopt this font on Linux desktops where Firefox is the browser your team actually uses and Twemoji's look is preferred over the distribution default. Skip it on machines where Chrome or Safari does the rendering, since those applications fall back to black and white outlines no matter how the font is installed. Before committing, open about:config in Firefox on one target machine and confirm the glyphs look right, because the README documents font family matching failures and the fontconfig fontlist workaround has a known crash history in Firefox releases before 48.

Frequently asked questions

Official sources

1. 13rac1/twemoji-color-font on GitHub
2. Issues
3. README
4. Releases