State of Text Rendering 2024

behdad.org/text2024 ​
behdad​
8 July 2024

[Leave comments: Google Docs, Hacker News, LWN, typo.social, X, reddit, phoronix]

License
This text is available under the Creative Commons Attribution-ShareAlike License 4.0.

TL;DR
In this survey paper, I cover advances in the OpenType standard and the Open Source text
stack and applications since 2009. I also discuss the future advances currently underway.

In broad strokes, OpenType added support for color fonts, variable fonts, and the Universal
Shaping Engine. The Free & Open Source stack supports all of these advances at the lower
level, but application UI support has been slower to arrive. The Open Source text stack also
gained enormous market-share when Android and Google Chrome fully embraced it. Adobe
now integrates parts of the Open Source stack for OpenType shaping in their flagship
applications Photoshop, Illustrator and InDesign.

Looking forward, there is a Rust migration of the text stack underway, which will unify font
compilation and consumption under a safe programming language. Incremental Font
Transfer will stream fonts to web browsers. And my proposed Wasm-fonts will finally
enable correct rendering of the most complex writing systems that are not (and inherently
can not be!) fully supported by the OpenType Shaping model, and more expressive fonts for
simple writing systems like Latin.

Table of contents
License
TL;DR
Table of contents
Preface
Dedication
Prerequisites
Introduction
Looking back
OpenType
Color fonts
Universal Shaping Engine
Variable fonts
A trio of libraries
FontTools
FreeType
HarfBuzz
Maintenance
Cosimo Lupo
Werner Lemberg
Khaled Hosny
Applications
Fontmake alternatives
AFDKO
FreeType alternatives
CPU-based
stb_truetype
RustType
font.rs
GPU-based
freetype-gl
GLyphy
msdfgen
Pathfinder
Slug Library
NV Path Rendering
Performance comparison
HarfBuzz alternatives
ICU Layout
m17n
SIL Graphite
Wine
 AllSorts, RustyBuzz, Swash
Bidirectional algorithms
FriBidi
ICU bidi
SheenBidi
Printing
Cairo
Skia
Qt
Font configuration & selection
Fontconfig
Layout engines
Minikin
Pango
Raqm
Skia Text
QTextLayout
GUI toolkits
GTK
Qt
Flutter
EFL
Operating-systems
Android
ChromeOS
Linux Desktop
Web browsers
Google Chrome / Chromium
Firefox
Microsoft Edge
Safari
GNOME Web
Konqueror & falkon
Word processors
LibreOffice
AbiWord
Calligra Words
Google Docs
Design tools
Blender
GIMP
 Inkscape
Krita
Scribus
Adobe Photoshop, Illustrator, InDesign
Figma
Canva
Font design tools
FontForge
GlyphrStudio
Fontra
TruFont
BirdFont
FontLab
Glyphs
RoboFont
Terminal emulators
Terminal text editors
Emacs
Vim
Batch document processors & TeX engines
Typst
SILE
XeTeX / XeLaTeX
LuaTeX / LuaLaTeX
Fonts
Noto fonts
Noto fonts
Noto CJK
Noto Emoji
Google Fonts
The Web
CSS
HTML
WOFF2
Auto-hinting
psautohint
ttfautohint
Game engines
Godot Engine
Unreal Engine
Unity
Looking forward
Better-Engineered Font Formats
Boring Expansion: Incremental font-format improvements
avar2
Cubic glyf outlines
Variable composites / components
Beyond-64k
Better Ergonomics: Rust migration and unification
Font compilation
Font access and drawing
Shaping
Other layout efforts
Rasterizers
Font configuration and selection
Beyond Emulation: Fully-programmable fonts
Other efforts
Fontra
Incremental Font Transfer
Analysis
Strengths
Weaknesses
Opportunities
Threats
Other resources
Acknowledgements
About the author
Version history

Preface
In 2009 I wrote State of Text Rendering, as a high-level review of the Free Software text
rendering stack, with a focus on shaping, and mostly in the context of the GNOME Desktop.
Since then, I have spent around twelve years working on various Google products to
improve fonts and text rendering: all Open Source work.

When I wrote that text in 2009, my main assignment was to finish HarfBuzz. Around 2012
HarfBuzz became fairly complete, and my attention was shifted elsewhere. I was the
tech-lead of the Fonts & Text Rendering team at Google Internationalization Engineering,
which was then responsible for initiating and commissioning the Noto Fonts from
Monotype and Adobe. I realized that at Google we control every aspect of displaying text,
from design of the fonts to rendering them on billions of devices, except for the font format
itself. And with the emergence of emoji as Unicode text and a desire to render them using
text APIs, in 2013 I extended the font format to support color. It was an eye-opening
experience: to be not blocked by the font-format limitations. Font-format extensions
became a core part of my interest and responsibilities since.

End-to-end text rendering. laymanslayout.wordpress.com

Another big change in my career in this period was crossing the fence into the type design
side of fonts and, with others, building a font compiler called fontmake. As such, I include
font design and compilation in this paper as well.

In this overdue update, I survey advances in the OpenType standard and the Open Source
text stack and applications. I also discuss what the future might hold in this realm.

In true release-early & release-often tradition, I am publishing this paper without having
finished my research on all the applications and projects involved. I have left many TODO
items, and have left out many topics and projects that did not even occur to me to include.
Your comments and input are welcome. You can comment on the Google Docs version, or
contact me via email. My contact info is on my homepage. I plan to update this at least till
the end of 2024, and then publish a dated article that can stand as a historical artifact
similar to the 2009 article.
Fifteen years is a long time to write an update, and as a result this text is quite long, so I
apologize for that. The text is written roughly in a way that different sections can be read
independently, given the prerequisites are met. To this end, there is some redundancy in
the text, which I hope will not bore you to stopping reading.

Dedication
Dedicated to the memories of Emil ‘eae’ Eklund and Saber Rastikerdar.

With Emil I spent weeks improving Chrome text layout over the years.

Saber made beautiful Open Source Persian fonts; a dream of mine.

With Dominik Röttsches, and Emil ‘eae’ Eklund. Chrome hackathon. Intel office. Espoo, Finland.
2014.
 Saber Rastikerdar. 1986­–2023.

Prerequisites
I assume a high-level understanding of how text rendering works, for example, what
shaping is. If that does not sound familiar to you, you might want to review State of Text
Rendering (2009), Modern text rendering with Linux: Overview (2019), and the slightly
higher-level Text layout is a loose hierarchy of segmentation (2020).
 The data flow of text rendering. Modern text rendering with Linux: Overview.

Introduction
Computer fonts have a pedigree of over fifty years. Many font formats and paradigms have
come and gone. The so-called Font Wars of the 1990s resulted in the introduction and
dominance of OpenType fonts as the lingua franca of digital text, both for type design and
consumption.

The 3 major implementations of OpenType in 2024 are:

-​ DirectWrite, the successor to Uniscribe, is Microsoft’s native implementation.

Although it is not used in Microsoft Edge (more on that in the next chapter),
-​ CoreText, the successor to ATSUI, is Apple’s native implementation,
-​ FreeType + HarfBuzz, constitute the Open Source implementation.

Apple also has their own original line of TrueType, which evolved into being called Apple
Advanced Typography (AAT), as an alternative to OpenType. Since the 2010s Apple has also
embraced OpenType for their new font families, yet many important families still remain as
AAT fonts on Apple’s platforms, and as such supporting AAT in the Open Source stack is
essential for a smooth experience on such platforms.

Adobe also had their own original line of OpenType implementations, but as far as we
know, they have stopped maintaining them and in the process of replacing them all with
the Open Source stack.

Monotype has their own line of OpenType implementations too, and as far as we know,
they still maintain them—especially for specialist domains like embedded devices
(including printers). They also sell support for the Open Source stack to their customers
(since those customers often adopt Open Source stuff lying around to get started and then
later develop needs that they want to hire a vendor to fulfill).

In this paper I survey the Open Source fonts and text production and rendering landscape
advancements over the last fifteen years, and shed light on what is underway.

Looking back
In this chapter I will survey the advances made in the last fifteen years in the landscape.

OpenType
OpenType saw quite some activity between 2014 and 2016, but then became dormant,
with the editor (Peter Constable) being assigned to other projects, then leaving Microsoft,
and joining back later as editor again. There has been recent activity on the color fonts
side, and new proposals, which I cover in the next chapter.

FontTools, FreeType, and HarfBuzz all support the new features. More on those below.

Color fonts
Color fonts turned out to be a disaster:

●​ By 2012 already Apple shipped their sbix format for their emoji font, without any
standardization. This was later contributed to OpenType in 2016,
●​ In 2013 at Google I made our own, Open Source, format called CBDT/CBLC based
on the existing architecture of OpenType monochrome bitmaps, for Android emoji
use,
●​ A couple months later, Microsoft released their COLR solution, which was a
solid-colored set of layers rendered on top of each other, which matched their
Metro design language of the time. This is now called COLRv0, as it was extended
later in COLRv1 (more on that below),
●​ Lastly, Adobe and Mozilla were working on a SVG solution which was released soon
after.

Of these, sbix and CBDT/CBLC were based on PNG bitmaps; COLR supported vector
outlines but only solid colors, and SVG supported arbitrary vector graphics, but depended
on an external specification generally understood as overly-complicated. Later in 2016,
COLR needed no updates to work along with Variable fonts (see below), and so was the
only color format that supports variation, and likewise the only variation format that
supports color. So, no one solution covered all the use-cases. It took quite a few years for
the different formats to make their way into browsers and other applications. The
aptly-named colorfonts.wtf website summarizes support across browsers and applications.

Markedly, Chrome and Android made a policy decision to never ship the SVG solution for
architectural reasons, which limited that format’s reach. But Google desired a vector format
with color gradients. In 2019, together with Dominik Röttsches of Chrome and Roderick
Sheeter (Rod) of Google Fonts, we developed a proposal for COLRv1. It took a few years,
but in collaboration with Microsoft, it was finally added to OpenType around 2022, and
shipped in Chrome and Android among other systems soon after – but remains
unsupported in Safari, Adobe flagship applications, Figma, etc. Like its predecessor
COLRv0, the new COLRv1 also supports font variations natively.

The Google Fonts team has developed a color-font compiler, nanoemoji, that can build
fonts in a variety of formats. The tool is used to build Google’s and Microsoft’s color emoji
fonts.

colorfonts.wtf
Universal Shaping Engine
By 2013 HarfBuzz was fully up to date with Microsoft’s OpenType shaping implementation
(sometimes vis-à-vis bugs), having finished the Indic shaping and the more recent
Myanmar shaping. Jonathan Kew and I, in collaboration with Martin Hosken of SIL, added a
new shaper called the South-East Asian (SEA) shaper, based on a simplified model of such
scripts. We presented this to industry partners at an OpenType meeting I organized in
Seattle (one of many meetings I hosted at various Google and Facebook offices in the years
since).

Then in 2014 at the Unicode Conference in San Jose, Andrew Glass of Microsoft presented
the Universal Shaping Engine, using similar ideas as SEA but much more complete. As a
result, we implemented it in HarfBuzz and deprecated and removed the SEA shaper. The
new shaper is capable enough to take care of most complex scripts being added to
Unicode, such that no new shapers have been needed since.
 Visualized form of standard cluster in the Universal Shaping Engine. Microsoft.

Variable fonts
In 2014 I decided to revive an idea from the 1990s, which was font interpolation at
run-time. This used to exist in Apple’s TrueType GX and Adobe’s Multiple Master (MM)
technologies, but did not survive in the OpenType, as MM was deemed too complicated to
maintain and removed from the early OpenType spec. Peter Karow’s IKARUS (1973) and
then Donald Knuth’s METAFONT (1977) technologies were built on similar ideas in the
1970s, but at font generation time. Karow showed ahead-of-time interpolation at ATypI in
1976. Although, the idea of font interpolation itself goes back at least to the 1885 Benton
Pantograph.

Throughout 2015 I advocated for the idea, and in February 2016 I released a blueprint for
the work. In a six-month collaboration that followed between Adobe, Apple, Google,
Microsoft, and invited industry experts, the feature was added to OpenType 1.8 and called
Font Variations, with such fonts called variable fonts. Tom Rickner summarized the
background to variable fonts in this writeup.

In a nutshell, whereas previously OpenType fonts were scalable, i.e., the font size could be
arbitrarily changed (being vector fonts), with font variations, other aspects of the font,
including custom aspects, can smoothly vary in shape. These aspects include, but are not
limited to, font weight, width, slant, and optical size.

The v-fonts.com website has a nice collection of variable fonts from a large variety of
sources and licenses, while Google Fonts has commissioned the largest single collection,
all available under the Open Font License. v-fonts.com/support also maintains an excellent
list of popular design application support status. Try moving the sliders to see what
variable fonts can do. For more resources on variation fonts, see Axis-Praxis resources.
Illustration of a variable font ‘Design space’ with weight & width axes, from John Hudson’s detailed
2016 announcement article, commissioned by Microsoft.

A trio of libraries
Currently most Open Source font compilation is done with a slew of Python libraries and
tools, all built on top of the FontTools platform. Font consumption on the other hand, is
usually built on top of two libraries: FreeType (for general font processing with C and often
rasterization) and HarfBuzz (for general font processing with C++ and very popularly for
shaping).
FontTools
FontTools was originally started by Just van Rossum in 1999, as a font
assembler/​disassembler (ttx), an XML format for representing font tables (.ttx), and a
Python API (fontTools). The XML quickly became (and still is) the de-facto way to
represent font binaries in a human-readable format. The XML format even appears in
Yannis Haralambous’ massive tome from O’Reilly, Fonts & Encodings. Just’s intention was to
build a font editor in Python on top of FontTools. In his words: “The intended font editor
didn't materialize at the time. Several attempts later, we now have Fontra :).”

By 2013 when I wanted to contribute to the library, the project was mostly dormant. After
failing to get any response from Just, I forked the project and, with a team at Google,
invested in vastly developing it and building the fontmake compiler on top. I managed to
finally connect with Just in 2015, and he has become an active developer of FontTools
again, while I maintained it for a while, before handing out maintenance to Cosimo Lupo,
who was then at one of the largest font development firms in the world, Dalton Maag, and
later joined the Google Fonts team.

Other than support for color fonts, variable fonts, and other table additions, FontTools has
gained quite a few higher-level modules, and absorbed some others from external projects.
These include: a font subsetter, a variable font (partial-)instancer, and code to work with the
Unified Font Object (UFO) font source format.

The fontmake compiler is built on top of modules including ufo2ft, glyphsLib, cffsubr,
skia-pathops, ttfautohint, and various FontTools modules.

Adobe open-sourced their Adobe Font Development Kit for OpenType (AFDKO) in 2014.
Over time, however, most interest has moved to the FontTools/​fontmake ecosystem.

Fontmake is in use by small and large type foundries equally, specially for reproducible
builds and continuous integration (CI). Since FontTools is the experimentation platform for
most Open Source font format development, fontmake tends to be updated to bring new
features to life faster than other compilers, proprietary or open.
 fontmake’s partial dependency graph, with fonttools at the base. pipdeptree.

FreeType
FreeType is a font access library and rasterizer, a C library originally developed by David
Turner in the 1990s. FreeType is continued to be maintained by Werner Lemberg. The
project saw significant contributions from Adobe in the form of a new CFF rasterizer
(2013), and CFF2 variable font support (2016). Other major changes include gaining
support for all color font formats including the recent COLRv1 (contributed by Dominik
Röttsches), full variable fonts support (with a lot of additions by yours truly), and a new
improved ftinspect utility, which was a Google Summer of Code student project.

Fuzzing and security bug fixes are often contributed by Google developers, as discovered
by the oss-fuzz and Chromium fuzzing ecosystems. FreeType is a core component of text
rendering, from embedded devices to all modern Linux desktop environments, to Android
and ChromeOS, bringing the total installations well into the billions. FreeType is an aging
C library. Buffer overflows and similar memory issues have caused several CVEs and even a
0-day in Apple products! While fuzzing has helped a lot with fixing such bugs proactively,
the desire to move to a more modern solution written in a safer language remains high.
There have been several attempts, including many in the Rust ecosystem. I will cover those
in later sections.

To date, FreeType has had 109 CVE records.

 New ftinspect utility. The FreeType Project.

HarfBuzz
HarfBuzz is a text shaper written in C++ with a C API. These days it supports both OpenType
and Apple Advanced Typography (AAT) shaping models. I started working on it in 2005. The
rewritten version, codenamed harfbuzz-ng, was ready for public use around 2012, as a
collaboration with Mozilla’s Jonathan Kew. Since then, we have kept it up to date, fixing
bugs, improving performance, and adding new features beyond text shaping. More recently,
David Corbett took over the maintenance of South-East Asian script support, and Khaled
Hosny took over maintenance and bug triage, while I continue as the lead developer.

When I moved from Red Hat to Google’s Chrome team in 2010, one of my main motivations
was to gain new market share for HarfBuzz, since the Linux desktop market was not big
enough to justify continued investment in HarfBuzz, and making it relevant to font
developers. Since then, HarfBuzz use saw a proliferation when Android shipped it, and
Chrome and Firefox switched to using it on all platforms. It is also in use on all Linux
desktop, ChromeOS, LibreOffice, OpenJDK, XeTeX, and many other projects, as well as
proprietary systems like Adobe’s Photoshop, Illustrator, and InDesign, PlayStation, most
smart TVs, and as far as Microsoft’s Edge browser (by way of Chromium).

The biggest addition to HarfBuzz in terms of non-shaping features has been a font
subsetter and variable font (partial-)instancer, led by Google’s Garret Rieger and Qunxin Liu,
respectively. These are used in various apps for printing, plus fueling Google Fonts, and in
the future, Incremental Font Transfer (more on that in the next chapter).

While HarfBuzz does not come with a rasterizer, it has draw & paint APIs that can be
connected to existing graphics engines to render monochrome and color fonts. This is in
use by several web applications using HarfBuzz, and FontGoggles, an Open Source Mac-only
font inspector and viewer developed by Just van Rossum and supported by Google Fonts.

Thanks to continued demand by Chrome, Android, and Google Fonts, HarfBuzz run-time
performance and memory usage are best in the industry.

Using HarfBuzz on the web has been on the rise, first transpiled to JavaScript, and more
recently cross-compiled to WebAssembly, through harfbuzzjs. Apps like Photopea, an online
photo editor, use it that way. Crowbar by Simon Cozens is an OpenType shaping debugger
web-app built using the HarfBuzz buffer-messaging API. Sploot is another web-app by
Simon, a font inspector. Prezi and Figma also use HarfBuzz in their web-apps.

HarfBuzz has been ported to Rust and Go, and has inspired several shaping
implementations in various languages. It has bindings for quite a few languages. As part of
the merger of Mono and .NET, HarfBuzz is now part of the .NET API.

HarfBuzz has embraced oss-fuzz fuzzing religiously. As of this writing, HarfBuzz has had
only 9 CVE records; 8 of which are denial-of-service, and only one is bad memory access.
 Complex text: without and with proper shaping, in various scripts. John Hudson.

Maintenance
All three projects have a fairly healthy Open Source life and community. They each have a
lead maintainer, plus one or two active developers, and a long tail of less-involved
developers and contributors.​
​

Maintainers of HarfBuzz, FreeType, and FontTools.

You might be surprised to learn that these three fundamental libraries are maintained by
three developers with curious backgrounds and no formal computer science education:
Cosimo Lupo, Werner Lemberg, and Khaled Hosny.

Cosimo Lupo

maintains FontTools. Cosimo studied anthropology, before becoming a font engineer and
then software developer in London. All because he liked a particular print font so much!
Here’s how he described it:

Back in the uni days, I was a bookworm and was fond of a particular custom Garamond
(technically a Jannon) typeface from a highbrow Italian publisher (Einaudi) so much so I
wanted to use that font for my dissertation. But it wasn’t commercially available so I
ended up getting in touch with a guy who was working on upgrading the font from
Type1 to OpenType and even drew myself the alternate lining numerals (which are never
used in the publisher’s printed books). This all in my spare time while actually studying
for the dissertation. After graduation I realised the hobby could become a profession and
got the DaMa internship and the rest is history

Werner Lemberg

has been maintaining FreeType for over two decades. Werner is a trained musician and has
been a répétiteur at various opera theaters in Germany and Austria. In his own words:

Around 1989 I wanted to write a paper on the Chinese mouth organ, the shēng (笙), and
I also wanted to have Chinese characters in the text typeset by the computer and not
inserted by hand. At that time there existed just a few, quite expensive programs for
MS-DOS which could do that. And there was LaTeX: I was told that it actually could do
what I wanted to achieve. This was my start into the world of typography.

Around 1990, only CJK bitmap fonts were freely available, and LaTeX had no support for
CJK outline fonts. However, a few years later I discovered the TrueType format, finally
providing good outline CJK fonts that came with no extra cost as part of Windows 3.1. I
was quite excited and even considered writing a freely available rendering engine, but
fortunately I found David Turner's FreeType project in 1995 that aimed at being a
full-featured TrueType interpreter and rasterizer, and I soon became an active developer
and later on the maintainer of this package, who I am still today.

Watch Werner and his daughter perform at ATypI 2013 Amsterdam.

Khaled Hosny

is the current maintainer of HarfBuzz. Khaled was a radiologist before becoming a full-time
font engineer & software developer, based in Cairo, Egypt. His interest in fonts started with
wanting a nice Arabic Naskh font. He tweeted about it here. He has also been instrumental
in switching miscellaneous Open Source apps to use HarfBuzz:

So far I've helped (in a way or another) migrating LibreOffice, XeTeX, Scribus, Emacs and
LuaTeX to HarfBuzz (as well as ImageMagick, Pillow and others, via Raqm).

Khaled Hosny—fixing libre text layout one application at a time. [*]

​
xkcd: Dependency.

Applications
In this section I review the most prominent Open Source applications of text layout, by
category.
Fontmake alternatives

AFDKO

Adobe Font Development Kit for OpenType (AFDKO) was open-sourced in 2014. Usage
never picked up in the Open Source world, as fontmake was quick to fill the need for a
solid compiler. AFDKO for the most part supports CFF-flavored OpenType font production,
and not TrueType-flavored (the more common) one. Fontmake supports both, including
variable fonts in both formats (CFF- one implemented by Adobe).

Development has slowed significantly since many influential Adobe engineers working on
the code retired.

FreeType alternatives
The 2010s saw the emergence of a number of font rasterizers, most on the GPU.

CPU-based

FreeType remains the most commonly used Open Source font rasterizer. It is CPU-based.
Other CPU-based solutions include: stb_truetype, RustType, and font.rs.

stb_truetype

is a single-header font library and CPU-based rasterizer, and sometimes used by smaller
products with limited resources. Note: It cannot handle untrusted font data securely.

RustType

from the Redox OS project, is a FreeType alternative written in Rust, without the hinting
engines.

font.rs

by the Raph Levien of Android and other fame, was developed in Rust as another
CPU-based rasterizer, claiming to be the fastest rasterizer in the world. Only works with
TrueType-flavored (ie. quadratic Bézier) OpenType fonts, not CFF-flavored (ie. cubic Bézier)
ones.
fontdue

claims to have "the lowest end to end latency for a font rasterizer". It pre-processes fonts
when loading them and converts them into custom data structures that enable very fast
rasterization. It does not rely on the Rust standard library, making it usable in embedded
environments.

GPU-based

Several GPU-based rasterizers were developed, of varying quality and sophistication. Some
are listed below, most using OpenGL shaders and are Open Source. (TODO: Add notable
clients of each.)

Whereas the existing, CPU-based, rasterization is typically coverage-based, ie.

approximating the portion of each pixel covered by the shape, since a paper by Valve
introduced them in 2007, Signed-Distance Field (SDF) text-rendering became a hot topic of
research and experimentation.

Nicolas Rougier and I surveyed the rasterizer landscape in our SIGGRAPH Digital Typography
mini-course in 2018. That slide-deck includes much more detail and a list of great further
reading material and references.

freetype-gl

by Nicolas Rogier is a SDF-texture-based rasterizer.

GLyphy

by myself is a SDF-vector-based rasterizer. GLyphy does not handle overlapping glyph

shapes and hence is not appropriate for use with variable fonts without external overlap
removal operation.

msdfgen

by Viktor Chlumsky is a multi-channel, improved SDF-texture-based rasterizer.

Pathfinder

by the prolific Patrick Walton, is by far the most advanced rasterizer, combining a whole
array of techniques and tricks to speed up rasterization. It was developed as part of
Mozilla’s Servo web rendering engine. Unfortunately the project does not seem to be under
active development.

Slug Library

by Eric Lengyel, is a promising but proprietary rasterizer based on the analytical solution.

NV Path Rendering

by NVIDIA, is a general path-rendering solution embedded in NVIDIA’s proprietary GPU

drivers. It is not particularly text-oriented, but does have some support for TrueType outline
rendering.

Performance comparison

Here is a dated performance comparison chart from the Pathfinder project. FreeType
performance has been improved since, thanks to the FreeType developer Alexei
Podtelezhnikov. Note that rasterization time often contributes only a small fraction to the
actual rendering time due to glyph and font caching. The exception to this is the
GPU-based approaches that try to rasterize on every frame, with no caching.

Rasterizer performance comparison of a few rasterizers. Patrick Walton.

HarfBuzz alternatives

ICU Layout

The ICU Layout Engine (ICU LE) shaper was deprecated and eventually removed from ICU,
in favor of HarfBuzz. My icu-le-hb library implements the ICU LE API on top of
HarfBuzz, which makes it a drop-in replacement for ICU LE.

m17n

The m17n shaper, which used Lisp as its expressive language, seems discontinued.

SIL Graphite

The SIL Graphite shaper gained support for advanced Nastaliq shaping, as used in SIL’s
Awami Nastaliq Urdu Nastaliq font. HarfBuzz can be compiled with Graphite support
enabled, which will use SIL’s Open Source graphite2 library to shape Graphite fonts.

Since Chrome and Android do not ship the Graphite backend to HarfBuzz, market-share
remains small. Firefox supports Graphite using libgraphite2 directly, as does XeTeX.
LibreOffice requires that HarfBuzz be compiled with libgraphite2 support.

Wine

Technically not a shaping engine, but Wine includes implementations of Microsoft’s

Uniscribe and DirectWrite shaping engines. This makes wine perhaps the largest
outstanding Open Source project that uses a shaper implementation other than HarfBuzz.
The API mismatch between HarfBuzz and Uniscribe / DirectWrite makes integration
difficult.

AllSorts, RustyBuzz, Swash

Three HarfBuzz-inspired shapers written in fully safe Rust.

AllSorts seems to be missing the Universal Shaping Engine among other features.

RustyBuzz is currently the most up to date with the latest HarfBuzz.

Swash seems dormant, with developer Chad Brokaw’s time spent on Google’s fontations
these days. More on that in the next chapter.
Bidirectional algorithms
All three engines below are up to date with the latest version of the Unicode Bidirectional
Algorithm and the Unicode Character Database.

FriBidi

by Dov Grobgeld and I, is the industry standard compact implementation of the

bidirectional algorithm.

FriBidi is the first major Open Source project I contributed to, back in 1999. It is how I
learned programming in C.

Being LGPL-licensed, FriBidi cannot be easily used in proprietary and embedded systems
without a commercial license.

ICU bidi

by the ICU project remains the heavyweight of bidi implementations, used by projects that
can afford shipping or linking to ICU, like Chromium and Android.

SheenBidi

by the Tehreer effort, is the new contender on the block. It has the advantage of being
small and having the permissive Apache license.

Printing
Printing these days often happens by way of outputting PDF from graphics libraries. Since
PDF is already laid out, there is no need for shaping when displaying PDFs (on paper or
screen). As such, fonts can be trimmed down to remove layout-specific parts when
embedding in the PDF.

PDF supports a limited number of font formats, and has not (and probably will not) be
updated for the OpenType color fonts and variable fonts formats. Instead, variable fonts
need to be instantiated to a static font before being embedded in PDF. Color fonts on the
other hand can encode the drawing commands in what is called a Type 3 font in the PDF.

Normal fonts are also subsetted to just the glyphs used, or sometimes a new font is
synthesized from scratch from the outlines of the original font.
Cairo

The Cairo 2D graphics library, while on life support, has solid PDF / PS output, including
custom font subsetting logic, thanks to Adrian Johnson. Adrian, Matthias Clasen, and I have
implemented color fonts and variable fonts support in Cairo. Cairo still is the underlying
graphics system of GTK and hence the GNOME Desktop, and the only maintained graphics
backend to the Pango text layout library (pangocairo).

Skia

The Skia 2D graphics library, used by Chrome and Android among others, has solid PDF /
PS output thanks to Google’s Ben Wagner on the Skia team. This includes font subsetting
logic using the HarfBuzz subsetter.

Skia, while better maintained than Cairo, has grown to be Too Big. It is such a fast-moving
target with unstable API/ABI, that it is a pain to use in smaller applications.

Qt

The Qt toolkit, used by KDE among others, provides printing facilities. It consists of a
custom font subsetter that has been around since ~2005.

Qt in general supports color fonts and variable fonts, but I am uncertain that those are
supported in the PDF generator currently.

Font configuration & selection

Android has its own, hardcoded, XML-based font configuration system, with Minikin (see
below) implementing the font fallback logic. Others in the Open Source platform usually
use fontconfig. This includes the major toolkits GTK and Qt on Open Source platforms, plus
ChromeOS, and Linux versions of Chrome, Firefox, LibreOffice, etc.

Fontconfig

Fontconfig, originally written by Keith Packard, is the de facto standard of font

configuration and selection on Linux and similar platforms. I inherited maintenance of
fontconfig from Keith Packard, and later handed it down to Akira Tagoh of Red Hat. The
project is alive but low in changes. I have implemented color font and variable font
support.
The problem with fontconfig is its overly expressive XML configuration language and
font-selection model. It is a dated design in need of a replacement. I have ideas, but they
are not developed yet. The Rust migration (covered in the next chapter) might be a good
😀
time to redesign fontconfig. Or we can call Lennart Poettering in.

Layout engines

Minikin

Minikin, originally by Raph Levien, underlies text layout in Android. It is built on top of
HarfBuzz, ICU, and is combined with Skia as the graphics system. It has little use outside
Android.

Pango

Pango underpins GTK toolkit and GNOME Desktop, among other applications. Pango uses
FriBidi and HarfBuzz on all platforms, and FreeType & Fontconfig on Open Source
platforms. Pango’s primary integration, and the only one actively maintained, is with the
Cairo graphics library: pangocairo.

Since I moved from Red Hat to Google in 2010 and my focus shifted on HarfBuzz solely,
Pango became unmaintained, until Matthias Clasen, the GTK maintainer, picked it up.

Pango development has been slow, but as my own testing bed for new features, Pango has
properly been ported to use HarfBuzz on all platforms, and added color font and variable
font support in the pangocairo backend.

Raqm

Raqm or libraqm, by the Omani HOST team and led by Khaled Hosny, is a nimble but
important layout engine built on top of FreeType, FriBidi or SheenBidi, Fontconfig, and
HarfBuzz. It is designed to be easy to plug into applications that previously performed text
rendering using FreeType, with no bidirectional or complex text support.

The Omani HOST team also ported several such applications to use Raqm. According to the
project homepage, Raqm is used in ImageMagick, LibGD, FontView, Pillow, mplcairo,
CEGUI, among others. There are patches for SDL_ttf, Pygame, and Blender.
Skia Text

The Skia 2D graphics library implemented text layout in terms of the Text API. See it in
action on the Skia CanvasKit WebAssembly demo page.

Prominent users include the Open Source Flutter GUI toolkit from Google, and Zoho Writer,
a Google Docs-like word processor that runs in the browser.

QTextLayout

QTextLayout, part of the Qt Project, is the layout engine underlying KDE, among other
apps. It has been ported to the new HarfBuzz, and uses HarfBuzz on all platforms for a
while now. Qt uses its own BiDi algorithm that should be fully up to date and compatible
with the latest version of the Unicode spec.

Qt supports OpenType Layout features in the API.

Color fonts are supported, but currently Qt does not support all color font formats on all
platforms. Qt does not do any rasterization of these itself, but depends on system rasterizer
for this. Specifically, Microsoft COLR fonts are only supported on Windows at the moment
(although Freetype support should also be possible). And SVG-based color fonts are not
supported on any platform.

Variable font support was expanded recently. A user can select specific named instances of
the font the same way they would previously select sub-families. In addition, custom
values can be supplied for any axis using API which was added in Qt 6.7.

There are three different approaches which can be enabled depending on user preference
and use case for rasterization and rendering:

1.​ Glyphs pre-rasterized into an atlas by system rasterizer at specific size.

2.​ SDF-texture-based atlas stored in texture and sampled in fragment shader.
3.​ Curvature data passed as vertex attributes and distance to curve calculated in
fragment shader, which is more expensive but does not have the artifacts caused by
the SDF-texture-based approach.

For more on these features see this post.

GUI toolkits
Generally, the toolkits commonly in use do not render text correctly, as described in this
article from 2015. The lack of linear alpha blending and gamma correction leads to
suboptimal looking text on both bright and dark backgrounds, compared to Windows and
macOS. The notable exception is Qt 5.9+ when rendering CFF(2) fonts (font files usually
with the .otf extension), which will automatically do the right thing. You’ll see that CFF(2)
fonts render thicker compared to the same font version as a TTF file.

GTK

GTK, renamed from GTK+, is the GUI toolkit underneath the GNOME Desktop, among other
applications. GTK 3 was released in 2011 and inherited the capable text layout engine
Pango from the GTK 2 era.

GTK 4 released in 2020 still uses Pango, and Cairo for graphics. But graphics composition
moved to the GPU.

GTK 5 is currently under design. There have been experiments with GPU-based rasterizers,
but there have been no conclusions yet. Matthias Clasen wants to remove the dependence
on Pango and to absorb the HarfBuzz-based text layout from Pango into GTK itself. At this
point, it seems unlikely that the absorption happens in GTK 5, but if and when that
happens, it will endanger other users of Pango significantly.

Qt

Qt has two main UI toolkits: Qt Widgets and Qt Quick. The former is C++-based and
software-rendered and the latter is hardware-rendered and the frontend is typically written
in a Javascript-like markup language called QML.

The fundamental font and text handling is shared between the two, using QTextLayout as
the main entry point, but Qt Quick has more options for how the text is rendered, as listed
earlier under QTextLayout.. Qt Widgets will always use the pre-rasterized glyph atlas
approach.

Qt enumerates fonts using system functions and applies its own font matching logic.
Harfbuzz is used for shaping once a font has been selected.
Flutter

Google’s Open Source Flutter GUI toolkit released in 2017 originally used a fork of the
Android Minikin layout engine (called libtxt). That has been retired in favor of the Skia
Text layout engine.

EFL

EFL text rendering is built on top of FreeType, Fontconfig, and HarfBuzz. Color fonts (color
emoji use primarily) are supported, Bidirectional text as well. Rasterizing is left to FreeType
with accelerated rendering done via font glyph texture atlases and triangle geometry pairs
per glyph to lay out if using GPU acceleration. In software rendering, gylph data is
compressed runtime with RLE 4 bit (or raw 4bit, depending on glyph size) to speed up
rendering via fewer memory accesses.

Operating-systems

Android

Google’s Open Source Android mobile and tablet operating-system has excellent support
for complex text, color fonts, and variable fonts. It uses its bespoke Minikin layout engine,
which in turn was ported, originally to HarfBuzz.old, and later to harfbuzz-ng, the current
version of HarfBuzz. It uses ICU for bidirectional text and other Unicode APIs, and FreeType
for font loading, through the Skia 2D graphics library.

ChromeOS

Google’s Open Source ChromeOS laptop operating-system is primarily based on the

Chrome browser and custom code for UI. ChromeOS text support is as good as Chrome’s in
general, which includes solid complex text, color fonts, and variable fonts support.

Linux Desktop

Mostly based on either GNOME or KDE desktops, both of which have solid text rendering
support, using Fontconfig, FreeType, and HarfBuzz as common components, by way of the
GTK and Qt GUI toolkits respectively.
Web browsers

Google Chrome / Chromium

Google Chrome and the Open Source Chromium browsers use Google’s Open Source Blink
engine. Google forked Blink from Apple’s Open Source WebKit engine.

Unlike its parent, WebKit, Blink uses HarfBuzz on every platform. This allowed for
removing multiple layers of abstraction from the code-base, simplifying its extension and
maintenance. It also enabled using HarfBuzz’s auxiliary API and features that are not
available through native libraries (Microsoft’s DirectWrite and Apple’s CoreText).
Shaper-driven font fallback and universal AAT layout support are two such features.

Moreover, Blink ships FreeType on all platforms. A hybrid rendering architecture was
devised by Dominik Röttsches, which allows switching to FreeType to rasterize newer font
technology (like color fonts and variable fonts) even on operating-system versions that do
not implement the feature in their system libraries. In this way, Chrome has an edge over
system-native browsers like Safari and the earlier versions of Microsoft Edge.

Chrome’s text rendering is led by Dominik Röttsches, after the late Emil Eklund moved
away from the project.

Chrome’s hybrid text rendering architecture. Dominik Röttsches.

Firefox

The Open Source Firefox browser uses Mozilla's gecko engine. It uses HarfBuzz on all
platforms. Gecko implements color font support itself, instead of using any other library.
Jonathan Kew is responsible for most text rendering at Mozilla.

An experimental engine Servo originally launched by Mozilla as a successor to Gecko, is

implemented in Rust. Mozilla eventually abandoned it when Mozilla Corporation
announced laying off a quarter of its staff in 2020 and transferred to The Linux
Foundation, then in 2023 to TLF Europe. While still experimental, it has been under active
development again since 2023. Servo currently uses Rust bindings to Harfbuzz.

Microsoft Edge

The successor to Internet Explorer released in 2015, using Microsoft’s DirectWrite library
(successor to Uniscribe) and Microsoft’s web engine. In 2018 Microsoft announced that it
will switch Edge to use Google’s Open Source Chromium project. The first such version was
released in 2020. Since this migration, and hence using the Blink engine, Microsoft Edge
now uses HarfBuzz for text shaping as well.

Safari

Apple’s flagship browser is built using Apple’s Open Source WebKit engine, and uses Apple’s
CoreText library (successor to ATSUI) for font processing.

Due to Microsoft Edge switching to Chromium, Safari is currently the only major browser
that does not use HarfBuzz for text shaping.

GNOME Web

The Open Source GNOME Web browser, formerly called Epiphany, and some other
browsers, use the webkit-gtk engine, a backend to Apple’s Open Source WebKit engine
(which is what Apple’s Safari uses). webkit-gtk uses FreeType and HarfBuzz for text
rendering.

Konqueror & falkon

The Open Source KDE browsers use the Qt WebEngine these days, which is based on
Chromium.
Word processors

LibreOffice

The Open Source word processor LibreOffice was forked from OpenOffice.org in 2010 (not
to be confused with another fork, Apache OpenOffice). An initial stable release was
provided in 2011. Collabora is the primary company behind LibreOffice, and it has garnered
orders-of-magnitude more users than other descendants of Sun’s StarOffice.

Thanks to immense efforts by Khaled Hosny and others, LibreOffice also uses HarfBuzz on
every platform, and advanced features like shaper-driven font fallback. LibreOffice’s complex
text support has been vastly improved, with solid bidirectional text support, shaping,
line-breaking, justification, as well as OpenType feature selection, color fonts (no COLRv1
yet), and variable fonts (only named instances currently), and uses HarfBuzz heavily for the
more modern features, especially in PDF export.

AbiWord

The GNOME-oriented AbiWord seems to have lost market share and resources to
LibreOffice. While still breathing, it seems to be on life support. By way of using Pango, it
seems to have some color-font support. Support for other modern font features remain
missing, probably indefinitely.

Calligra Words

Calligra Words replaced KDE’s KWord in 2012. It does not seem to support color fonts or
other modern font features. It seems to support basic bidirectional and complex text by
way of using Qt.

Google Docs

While not Open Source, Google Docs is worth mentioning as it has solid bidirectional and
complex text support.

There is no support for OpenType features. Color emoji work, but otherwise color fonts are
not an option. Variable fonts’ weight axis is the only axis that is usable, as there is no UI
for style selection other than the 9 weights + italics that were supported before variable
fonts.
Design tools

Blender

The Open Source Blender 3D creation suite currently does not support bidirectional or
complex text shaping. There exists a patch to use Raqm for text layout, which, if merged,
will make basic support available.

GIMP

The Open Source, GTK-based GIMP image editor currently uses the Pango layout engine for
text layout. Although there is support for OpenType features and variable fonts through a
plug-in, this does not have an interactive user interface. Currently, color fonts will
generally render either with their default colors, or in monochrome. Work is ongoing to
add support for OpenType features, variable font axes, alternate characters, and more,
using a new desktop font service, but this is at early stages.

Inkscape

The Open Source, GTK-based Inkscape vector editor uses the Pango layout engine for text
layout. At least some OpenType features are supported. Color fonts render in their default
palette. However, since Inkscape is an SVG editor, it is possible to add CSS properties to the
SVG using the built-in XML editor and achieve more effects.

Krita

The Open Source, Qt-based Krita image editor has fairly simple text support in its current
stable release, but work is being done to move to Raqm and libunibreak, and more.
Currently, OpenType features and color fonts are not supported, but the in-progress work
has been demonstrated and shows excellent results.

Scribus

The Open Source, Qt-based Scribus desktop-publishing application uses FreeType,

HarfBuzz, and other libraries directly. There is support for OpenType font features in the
Development release (1.7.0 was tested). Color fonts render in their default colors. There
does not seem to be support for variable fonts.
Adobe Photoshop, Illustrator, InDesign

Adobe’s proprietary flagship apps were updated between 2019 and 2023 to use HarfBuzz
under the hood of their World-Ready Composer.

Sadly though, the World-Ready Composer is not the default composer in Illustrator and
InDesign. As such, still many designers typeset text in complex scripts they do not read
using the default composer and get the wrong shapes. 😡Photoshop, however, uses a
Unified Text Engine. Unlike Photoshop and InDesign, the Illustrator switch to HarfBuzz was
never publicly announced.

It gets ironic: Here is a picture I took of a slide presented at a keynote by Pankaj Joshi of
Adobe at the BITS9 conference on typography in Chiang Mai, Thailand, in 2019, about
support for South-East Asian script in Adobe products:

Slide by Adobe product-manager Pankaj Joshi displaying broken complex text.

I kid you not: all complex text rendering in that slide is b0rked!
Figma

Figma is a proprietary design tool that works in the web browser among other platforms. It
uses HarfBuzz for shaping, and ICU’s bidi implementation.

There is an OpenType Layout features panel, where people can toggle the font features.

Figma does not currently support color fonts. Variable fonts are supported.

Canva

(TODO)

Font design tools

FontForge

The venerable Open Source font design tool from George Williams started its demise when
George retired from it in 2012. Since then there have been efforts (and a couple of forks,
including Sorts Mill by Barry Schwartz and Khaled Hosny) to keep it alive, but by the late
2010s the project had become dormant. Dave Crossland’s efforts to fund the project’s
development dried up.

FontForge is a large, aging C codebase (~1M SLOC) that crashes often and is hard to work
with. It lacks support for the more modern font features.

That said, FontForge is still the most viable font design tool available on Linux, and as
such still in use.

GlyphrStudio

An Open Source web-based font design tool that has been around since 2010, “focusing on
font design for hobbyists”.

Fontra

The new, Open Source and web-based, font design tool on the block, promises to transform
the Open Source font design tool landscape. I cover that in the next chapter.
TruFont

The Open Source TruFont was a short-lived effort by Adrien Tétar to build a UFO-based
font editor for Linux. A RoboFont (described below) clone of sorts.

BirdFont

A hybrid Open Source / proprietary font design tool for various platforms, including Linux.
While the Open Source & free versions seem to lack modern font technologies, the
commercial license is significantly cheaper than the prominent proprietary tools listed
below.

FontLab

The former champion proprietary font design tool FontLab had its first major release after
FontLab Studio 5 (2005) as FontLab VI in 2017. This added support for new technology like
color fonts and variable fonts. FontLab 8 is the current major version.

FontLab can import/export font sources from/to the UFO format, which enables
interoperability with the FontTools/fontmake ecosystem.

Glyphs

Built by a type designer, Georg Seifert, Glyphs is a proprietary font design tool for the Mac.
It was built partly by porting the fonttools font assembler to ObjectiveC by Georg. In the
2010s Glyphs rose the ranks to become the most-commonly used font design app amongst
new users big & small.

Glyphs 1 was released in 2011. Glyphs 2 released in 2015 brought support for color fonts,
and later 2.x versions brought variable fonts support in late 2016. Glyphs 3 released in
2020 is the current major release..

Glyphs uses its own text-based source file format, which the Open Source glyphsLib
package can read/write and export to UFO, enabling interoperability with the
FontTools/fontmake ecosystem.

RoboFont

Built by another type designer, Frederik Berlaen, the proprietary RoboFont is another font
design tool for the Mac, built in Python on top of the fonttools ecosystem, and with a focus
on Python scripting. It uses UFO as its native font source format, which makes
FontTools/fontmake interoperability a first-class experience.

RoboFont is taught at, and most commonly used by the graduates of, the TypeMedia MA
program at the Royal Academy of Art, in The Hague.

RoboFont supports variable fonts. (TODO What about color fonts?)

Terminal emulators
Many Open Source terminal emulators have added support for bidirectional text and
complex text rendering. These include Kitty and vte-based terminals (bidi only). Wez's
terminal emulator, wezterm, in addition to bidi has font shaping support using harfbuzz.

Egmont Koblinger, a vte developer, wrote Bidi in Terminal Emulators which lays out the way
vte works.

Here is a (probably outdated) gist of the terminal emulators supporting bidirectional text.
Here is another listing of terminals that support some minimum Unicode clustering. (TODO
What else?)

The Mac Terminal also supports bidirectional and complex text output. The new Windows
Terminal seems to have some basic bidirectional text and Arabic support.

Terminal text editors

Emacs

Emacs used to have support for the m17n shaper for complex text handling. Since Emacs
27.1, the default shaper is now HarfBuzz in the non-terminal versions of the editor.
However, Emacs uses HarfBuzz selectively: it has some regex that enables shaping only for
specific Unicode ranges. ASCII, for example, does not go through HarfBuzz by default.

Emacs uses a Lisp bidirectional algorithm implementation.

Vim

Vim has built-in bidirectional text and some Arabic shaping support. I am unsure about the
status of any further complex text support in the non-terminal versions of vim.
Batch document processors & TeX engines
The XML-based document processing workflow never really took off, at least not in the
Open Source world. The batch document processors that emerged are prominently
TeX-related: SILE, XeTeX, and LuaTeX.

Typst

A new Rust-based typesetting system using the HarfBuzz Rust port RustyBuzz for text
shaping. One of the Typst developers, Laurenz Stampfl, is influential to keeping RustyBuzz
up to date with the latest HarfBuzz.

SILE

The SILE Typesetter, originally by the project-minting-machine Simon Cozens and now
maintained by Caleb Maclennan, is a new typesetting engine. From the project page:
“Conceptually, SILE is similar to TeX—from which it borrows some concepts and even syntax and
algorithms—but the similarities end there. Rather than being a derivative of the TeX family. SILE
is a new typesetting and layout engine written from the ground up using modern technologies
and borrowing some ideas from graphical systems such as InDesign.”

SILE defaults to using Harfbuzz via Lua bindings (although using other shapers is possible)
and has full support for OpenType features and variable fonts and partial support for color
fonts.

XeTeX / XeLaTeX

XeTeX, as originally developed by Jonathan Kew, was a descendent of the eTeX engine,
using Apple’s ATSUI system library for shaping. In 2013, Khaled Hosny ported it to
HarfBuzz for shaping.

LuaTeX / LuaLaTeX

LuaTeX, the pdfTeX derivative adding Lua as an embedded script language, is the current
trunk of the TeX family. It uses pdfTeX for the (frozen) 8-bit engine.

Complex text support in LuaTeX is more complicated:

LuaTeX’s “philosophy” is that “it provides solutions, not answers”. So instead of integrating
with HarfBuzz like a normal application would do, it provides extensive callbacks that
allow Lua code to replace parts of the TeX machinery, including loading fonts and laying
out text.

The ConTeXt team (the main people behind LuaTeX, with ConTeXt being a macro package
alternative to LaTeX), have OpenType layout implemented entirely in Lua (originally it used
parts of fontforge, integrated into LuaTeX and exposed as Lua module, for loading fonts, but
it has since been doing in entirely in Lua, though the fontforge code is still part of LuaTeX).

Khaled Hosny provided HarfBuzz as another Lua module integrated into LuaTeX, then
updating the Lua code to alternatively use that module. But the LuaTeX team initially
rejected his code contribution, so Khaled forked it as harftex, but the LuaTeX team later
integrated his code without even consulting him. So harftex was retired.

The real use of HarfBuzz occurs in the luaotfload TeX/LaTeX package, and it remains to
be optional. See this article by Khaled summarizing his work.

Finally, LuaHBTeX, is LuaTeX with HarfBuzz bundled. It is the default binary for LuaLaTeX,
but using HarfBuzz still requires loading the luaotfload package and activating the
non-default HarfBuzz integration.

Fonts
Good Open Source fonts are a requirement of a great text rendering experience. While
there exist many Open Source high-quality font projects, two collections are worth calling
out: Noto fonts and Google Fonts.

Noto fonts

Google’s Open Source Noto fonts (Noto as in no tofu) are the default font family on Android
for writing systems other than Latin, Greek, and Cyrillic, which use Roboto. They replace the
earlier Droid fonts. Noto is, by most measures, the largest font family ever developed. It
comes mostly in Noto Sans and Noto Serif families, each of which contain more than
200,000 glyphs!

Noto fonts have been embraced by Fedora and other Linux distributions. Some parts also
ship in Apple products.

Noto is comprised of three components:

Noto fonts

Noto fonts for most writing systems were originally outsourced to Monotype. In 2014, while
at the Google Internationalization (i18n) Engineering team, with Roozbeh Pournader, we
convinced our management chain to get true font sources from Monotype, and to compile
them with a font compiler we would build, which turned out to be fontmake.

Other-Noto-fonts are maintained by Simon Cozens these days, supported by Google Fonts.

Noto CJK

The Chinese, Japanese, and Korean Noto fonts are co-funded by Google and designed by
Adobe, which itself outsources the design to major East-Asian type foundries. Adobe
releases the same designs under the Source Han Sans and Source Han Serif names.

Unfortunately, to my disappointment, the Noto CJK fonts and their Adobe counterparts are
not really Open Source. They are simply provided as in Free Beer, without true sources.

Noto Emoji

The Noto Emoji font was originally a monochrome font that emerged from Android’s Droid
Emoji fonts. I added support for building Noto Color Emoji in 2013, and since then it has
been ported to support COLRv1 and other color-font formats by the Google Fonts team.
These days, there is a monochrome, variable, font Noto Emoji, and a Noto Color Emoji for
the public to use, which is built using nanoemoji, a color-font compiler from Google that is
also used by Microsoft, among others.

Google Fonts

Google Fonts is Google’s font serving infrastructure and font directory/catalog, mainly
focused on CSS web fonts, but also “Downloadable Fonts” as part of Google Android (not
AOSP). Google Docs software engineer David Kuettel started the team in 2009 with his
colleague Jeremie Lenfant-Engelmann, and soon recruited Raph Levien (software engineer),
Dawn Shaikh (user experience research, with a PhD on font selection), Tobias Kunisch (UX
designer, who led design of catalog web app v1 for the 2010 launch at Google I/O and v2
in 2011), and David Wurtz (product manager). As a web application it is not Open Source,
but the fonts it serves are all Open Source.

Google Fonts commissions many new Open Source font families, and makes over 1700 font
families available under the Open Font License.
Google Fonts has the potential to streamline packaging of over a thousand font families by
Linux distributions, tight integration into Linux Desktop / ChromeOS font installation, and
online font selection and automatic installation. So far, neither of these potentials have
been explored, though there seem to be third-party apps to do font installation.

The Web
The web platform has kept up with new font-format features. See also the Web Alamanac
2024 chatper on fonts for some interesting stats on web font technology usage.

CSS

CSS has been updated to support various new font technologies:

-​ OpenType features are supported through font-variant (and its longhands) and
explicitly through the font-feature-settings properties.
-​ Color-font palette selection is supported through the font-palette property.
-​ Variable fonts are integrated into the font selection and resolution system:
font-size (size), font-weight (wght axis), font-style (slnt axis),
font-stretch/font-width (wdth axis), and font-optical-sizing (opsz
axis). Variations can also be explicitly specified using
font-variation-settings, though notably, that property does not cascade as
one would like.

CSS introduced the unicode-range property, which allows webfonts for larger writing
systems to be cut down into smaller chunks that can be downloaded separately as needed.
While this mechanism has its limitations, namely, breaking shaping across the different
chunks, it has had its use in webfont serving. It is my hope that it would be superseded by
the Incremental Font Transfer technology eventually.

CSS has also been updated to support the bidi isolates (through unicode-bidi), though
HTML's dir attribute is the recommended method for HTML documents.

HTML

An addition to HTML was dir=auto (which is the default value for <bdi>); it not only
applies isolation, but also uses UAX#9's first-strong heuristic to determine the
directionality of the isolation. (It's dumb and often wrong, but easily manipulatable and
gives results consistent with plaintext.)
HTML also silently updated its dir attribute to apply bidi isolation, instead of embedding.

WOFF2

WOFF2 is the second and vastly improved version of the Web Open Font Format. It is not a
new font format but a compression format for web fonts. It is backed by the
Google-developed Brotli compression format and an array of custom font table
transformations. It provides significant font file size savings over raw OpenType and the
previous WOFF format version 1.

Auto-hinting
Auto-hinters are part of the font design/production process. They produce font hinting data
to be embedded into compiled fonts, to improve rasterization at low sizes.

The Raster Tragedy is standard reading for understanding hinting. It was last updated in
2018.

psautohint

was born by extracting the CFF auto-hinting logic from Adobe’s open-sourcing of the
AFDKO by Khaled Hosny in 2016, before Adobe embraced it in 2018 and funded Khaled’s
work on it. It is the de facto standard for hinting CFF-flavored OpenType fonts.

It has recently been deprecated though, by a Python rewrite called otfautohint, which is
part of AFDKO and unfortunately not shipping as a separate project.

ttfautohint

by Werner Lemberg of FreeType fame, is a font ahead-of-time auto-hinter for

TrueType-flavored OpenType fonts, based on the FreeType run-time auto-hinter. Like the
run-time counterpart, it supports a wide variety of scripts, thanks to support from Google’s
Noto fonts and Google Fonts projects. Small and big type foundries alike use it.

Note that for technical reasons, ttfautohint has not been updated to support variable fonts.
Auto-hinting variable fonts across the designspace is a Hard Problem™.
Game engines

Godot Engine

The Open Source Godot Engine supports complex text rendering using HarfBuzz. (TODO:
Other features?)

Unreal Engine

The proprietary Unreal Engine supports complex text rendering using HarfBuzz. (TODO:
Other features?)

Unity

The proprietary Unity engine announced support for complex and bidirectional text
rendering using HarfBuzz and ICU in late 2024. (TODO: Other features?) Two open source
packages (Calligraphics and TextMeshDOTS) providing world space text rendering for the
Unity DOTS framework, have either announced or implemented HarfBuzz , to support full
complex and bidirectional text as well as COLRv1 fonts.

Looking forward
In this chapter I briefly survey what is underway in the font-format extension and the Open
Source ecosystem in terms of new developments.

Better-Engineered Font Formats

In 2021 I made a public presentation called Better-Engineered Font-Formats (slides / video
/ Simon Cozen’s notes), in which I laid a three-part plan for the future of the font format
and platform: Boring Expansion, Better Ergonomics, and Beyond Emulation. These ideas were
prototyped and further presented to the community and industry by Dave Crossland and I
at the OpenType 2.0 session at ATypI Paris 2023 (better slides / video).

Boring Expansion: Incremental font-format improvements

Boring Expansion is a collection of incremental proposed extensions to the font format
that I spec’ed and prototyped in FontTools and HarfBuzz (as experimental features) in 2022.
Since then, with the Google Fonts team, and technical-writing help from Liam Quin, we
have proposed them to the ISO OpenFontFormat. If accepted, they will eventually make
their way to OpenType, and other implementations.

The main proposals are summarized below. See the project page for more details including
motivation and specifications.

avar2

A simple but impactful update to the OpenType 1.8 Font Variations model, the avar
version 2 table enables many desired designspace configurations currently impossible.

Cubic glyf outlines

Cubic outlines in the TrueType-flavored OpenType glyf table will reduce font compilation
rounding errors and save a few percentage points in font-file binary size.

Variable composites / components

Variable composites / components is a font design paradigm where glyphs can be

constructed from varying components across the designspace. This can cause significant
font-file binary size savings for writing-systems like those used by Chinese, Japanese, and
Korean languages. In a test Korean (Hangul) font face, we have achieved a size reduction of
92% using this technology, resulting in a font that is only 8% of current OpenType
equivalent!

Beyond-64k

Beyond-64k aims to break the 64k limitation in the number glyphs per OpenType font. This
is important for developing complete Chinese, Japanese, Korean fonts given the addition of
many thousands of new ideographs to the Unicode Standard, and building pan-Unicode
font families like the Noto fonts.

Better Ergonomics: Rust migration and unification

While my proposed use of flatfonts fell flat on its face, better ergonomics for building and
consuming fonts have lived on in terms of Google’s Oxidize effort to port both font
compilation and font consumption (font access initially, followed by shaping) platform to
the Rust programming language. This has a huge impact on software security because of
Rust language’s safety guarantees while dealing with untrusted font data as in web-fonts.
Moreover, this has the potential to remove sandboxing of text rendering on certain
platforms, like Google Chrome.

Moreover, the fontations platform, which is the Rust framework Oxidize is producing, will
unify font compilation and consumption, reducing the number of places new font-format
features need to be implemented from three (FontTools, FreeType, and HarfBuzz) to one
(Fontations), which would reduce development cost and overhead.

Chromium Canary ships a font backend as an alternative to FreeType under a run-time flag,
and using fontations for certain less-commonly-used font formats.

Font compilation

Fontmake is to be replaced by fontc built on top of fontations.

Font access and drawing

One existing solution is RustType from the Redox OS project.

In the fontations land, FreeType is to be replaced by fontation’s skrifa. Subsetting is to be

replaced by klippa. Fontations does not itself contain a rasterizer (currently), but relies on
existing graphics systems for rasterization, which is the same way Skia (and hence Chrome
& Android) currently use FreeType.

Chad Brokaw has also been responsible for the monumental task of porting FreeType’s
TrueType hinter, CFF hinter, and autohinter to the fontations platform.

Shaping

HarfBuzz is most likely to be replaced by RustyBuzz, by Yevhenii Reizner (RazrFalcon), in

the Rust ecosystem. RustyBuzz uses Yevhenii’s ttf-parser for font access. There is a desire to
port RustyBuzz to use fontations instead, an effort called HarfRuzz.

RustyBuzz, a direct port, is not the only Rust effort to recreate HarfBuzz shaping. AllSorts is
another HarfBuzz-inspired Rust text shaping engine by YesLogic and extracted from the
Prince proprietary PDF generator. So is Chard Brakow’s more recent Swash.
Other layout efforts

Fontations is not the only Rust effort to build a modern text layout system. Other projects,
like cosmic-text, already ship respectable text layout systems in Rust.

Rasterizers

For rasterization, on the CPU there are: RustType, Raph Levien’s earlier font.rs, Chad
Brokaw’s more recent zeno, mooo's fontdue On the GPU, there is Patrick Walton’s earlier
Pathfinder, and Raph Levien’s more recent vello, which is a more experimental, general
vector rasterizer.

Font configuration and selection

Fontconfig-compatible font selection half-libraries exist in terms of fontdb by Yevhenii

Reizner, and fontique.

Bidirectional algorithm

There is the unicode-bidi crate by the Servo team.

Beyond Emulation: Fully-programmable fonts

Finally, I proposed that the future of font shaping and drawing/​painting will involve a
fully-programmable paradigm. I proposed WebAssembly (Wasm), and went ahead to
prototype the shaping aspect in HarfBuzz’s Wasm shaper using the wasm-micro-runtime
Wasm engine. Simon Cozens, as usual, implemented several impressive examples, because
why not!

Two tongue-in-cheek mis-uses of the HarfBuzz Wasm shaper appeared recently: the Bad
Apple font, and llama.ttf. Check them out! To be clear, in a solid implementation of the
Wasm shaper, acts like llama.ttf will not be possible because of CPU time budgets enforced.
Bad Apple will become much easier and faster when we introduce the draw API in Wasm.

I will delve on the motivations and design for this in a separate whitepaper, due to release
in a few weeks, if not days. (TODO: Finish whitepaper.)

There is currently work going on by Abdul Rahman Sibahi to add Harfbuzz-style Wasm
shaping to RustyBuzz using the wasmtime Wasm engine.
Drawing and painting API will eventually come to HarfBuzz, probably in 2025.

Other efforts

Fontra
While many attempts have been made into building open source font editors, and even
web-based open source font editors, by many venerable engineers, the Fontra app by Just
van Rossum et al. and supported by Google Fonts seems to be the one most likely to
succeed.

Fontra is under active development, and supports advanced features like multi-user
collaboration and the variable-components design paradigm. Check out the 1-hour
demonstration and discussion video.

Fontra uses .designspace + .ufo for storage, but can also use its own .fontra source
format. The .fontra format is not stable, and its structure is similar to
.glyphspackage. With some limitations, it can read .ttf, .otf (including variable
fonts) and .glyphs and .glyphspackage. Fontra’s server-side is built on top of the
FontTools ecosystem, while the client-side contains custom JavaScript code.

Incremental Font Transfer

Incremental Font Transfer (IFT) is technology under development at W3C and currently at
the Working Draft stage. It has been in the making since 2018, and currently led by Google
Fonts engineer Garret Rieger. Google Fonts’s Roderick Sheeter, Adobe engineer Skef
Iterum, and ex-Apple engineer Myles Maxfield have also made significant contributions.

The technology, when made available, allows for streaming fonts to web browsers and
other systems as support for new characters becomes necessary. This would significantly
reduce bandwidth required to use web-fonts for large scripts like Chinese, Japanese, and
Korean, and large font families like the Noto fonts, while maintaining shaping fidelity,
unlike the unicode-range hack. See Chris Liley’s recent IFT Explainer for details.

I outlined how such a protocol might work in my 2018 whitepaper Faster Horse. That
became the core of the dynamic-subsetting aspect of the technology. It defines a protocol
and is agnostic to specific server-side implementations. But one way this can work is to use
the fast HarfBuzz subsetter or another fast subsetter for live subsetting, diffing, and sending
font patches using the Brotli font compression platform. This was considered and evaluated
for several years. More recently, Adobe proposed an approach (called IFTB) that avoids
dynamic web-serving and uses static resources only, which would simplify the serving
component.

The two proposals have now been unified in a new specification, which still allows for
some dynamic subsetting and serving pre-computed font files and patches. The new
system provides a better balance between content-specific subsetting and CDN cache
performance.

A five minute demonstration video of the earlier protocol is available here.

Analysis
Here I do a brief SWOT analysis of the Open Source fonts and text rendering ecosystem,
mostly to show off my MBA training. 😁

The four components of SWOT in a 2×2 matrix. Wikipedia.

Strengths
Throughout the 2010s and due to global markets, the Open Source foundational text
rendering libraries FreeType and particularly HarfBuzz gained huge (possibly majority)
market share, thanks to Google’s Android and Chrome, but also a long list of smaller
platforms and products. This, then, forces type designers to test their fonts against the
Open Source platform, something that was not the case while the market share was
limited to Linux Desktop and a few obscure platforms.

Another strength of the Open Source platforms is its agility. Since the font stack is shipped
in small modules, they are each updated on their own (relatively fast) schedule. And many
big clients have very short release cycles: Six weeks for Chrome and Firefox, once-a-year
for Android, and almost instantly for the Linux distributions. This enables rapid
development and experimentation with new features and ideas. As the Chrome hybrid text
rendering architecture shows, this can give Open Source applications an edge over
proprietary competitors on non-Open Source platforms.

The usual Open Source benefits apply.

Weaknesses
Even with the market share, the Open Source platform has no authority. While Microsoft
and Apple can ship new font-format features and later shove them into the ISO
OpenFontFormat and OpenType, which the Open Source platform follows, these vendors
and specs do not follow updates to the Open Source platform in the same way. Whereas
Microsoft and Apple have shipped new font-format features and then contributed them to
the specs, protesting change proposals would disrupt their already shipping
implementations, Google Chrome will not ship non-standardized features because of its
intent-to-ship policy. This pushes shipping new features coming from the Open Source
platform corner of the industry to the tail end of the standardization lifecycle instead of its
head, which means a multi-year lag.

This is ironic, as Google funds new Open Source platform font-format developments, yet
Google Chrome refuses to ship until competitors ship them first! Why am I paid to do this,
again? Android is better, in that it is not bound by similar policies.
Opportunities
More applications, native or online, are moving to the Open Source platform than ever.
Even IKEA has switched to the Noto fonts in 2019! And Apple ships Noto fonts to round
out its platform type library and also offer complete Unicode coverage. This has brought
immense testing and user feedback to the platform. There is a great opportunity to get
even more organizations even more involved in developing the platform further.

A great example of this is: when the RustyBuzz port of HarfBuzz to Rust was declared
deprecated by its developer, Yevhenii Reizner, a Typst developer, Laurenz Stampfl, stepped
up to backport HarfBuzz shaping updates up to HarfBuzz version 9.0.0 to RustyBuzz, which
at the time was stuck at HarfBuzz 2.x!

Threats
The biggest threat to the ecosystem is that Google reduces resources it currently pours into
the ecosystem. Mozilla already cut most of its (much smaller) involvement, by way of
abandoning Servo and Firefox OS. The Linux Desktop has been benefiting from Google’s
investment into HarfBuzz, FreeType, and other projects.

While Chrome and Android will be with us for a while longer, Google Fonts invests the
most into the ecosystem, in terms of commissioning fonts (led by Dave Crossland), as well
as investing developer time in terms of contractors (including myself, Colin Rofls, Khaled
Hosny, and Simon Cozens) and full-time engineers (Chad Brokaw, Cosimo Lupo, Garret
Rieger, Roderick Sheeter, Qunxin Liu, and others). Google company-wide budget cuts
reaching the Fonts team pose the biggest threat.

While the Rust migration is beneficial to the ecosystem in the long term, in the short term
it has the potential to fragment the ecosystem and reduce resources (especially from
Google) available to the C / C++ and the Python platforms, which we need to update for
quite a few years more.

Other resources
Here is a collection of other resources:

-​ My homepage includes links to over two dozen presentations and papers I have
made over the years,
 -​ Digital Typography by Nicolas Rougier and I surveyed the rasterizer landscape in
2018. Includes much more detail, and a list of great further reading material and
references on the subject.
-​ The Raster Tragedy was updated, last in 2018, to include a growing number of
chapters on hinting and subpixel text rendering,
-​ The Bézier Primer by Pomax, is 101-reading for anyone interested in dealing with
vector fonts in their current Bézier form.
-​ Raph Levien’s blog and other writings cover the topic of graphics and text rendering
on the GPU from Rust,
-​ The typo.social Mastodon server is a social-network community for the type design
community,
-​ The FontTools and HarfBuzz GitHub discussion forums and issue trackers are a good
place to get help with many topics related to font compilation and consumption,
-​ You can always email me or tag me on X or typo.social. My contact information is on
my homepage.

Acknowledgements
I would like to thank the following people for reviewing drafts of this article as well as
insightful discussions: Bianca Berning, Dave Crossland, Eskil Abrahamsen Blomfeldt,
fantasai, Garret Rieger, Just van Rossum, Khaled Hosny, Lars Knoll, Liam Quin, Roderick
Sheeter, Skef Iterum, Werner Lemberg, and others I definitely have missed. All mistakes are
mine.

I also like to thank the Google Fonts team for supporting the production of this document,
and continued investment into the ecosystem.

About the author

Behdad Esfahbod is an Iranian-Canadian software developer and Open Source enthusiast
based in Edmonton, Canada. He is the primary author and developer of HarfBuzz, and has
over 25 years experience working on internationalization, fonts, and text rendering in the
Open Source ecosystem. He has worked at Google, Facebook, Red Hat, and the FarsiWeb
project.
When not hacking, behdad enjoys cooking, travel, photography, making short films, cars,
camping, and playing with his niece.

With Dominik Röttsches driving, in my 1974 MG MGB (R.I.P.). Redwood City, California. 2017.

Version history
-​ 2025-02-12 Export Google Docs to self-hosting, using gdocs-me-up.
-​ Rest of 2024 Improve based on received feedback.
-​ 2024-07-08 Initial public release.
Type-design industry mingling. Berlin, Germany. 2016.