Python runs the font world, just not the screen

Is Python the most popular font stack? At the layer where fonts are made, yes, and it is not close. The tools that compile font sources into binaries, inspect and repair files, subset fonts for the web, and run quality checks before release are overwhelmingly Python, and most of them stand on one library: fontTools, started in 1999. What Python does not do is put text on your screen. Rendering belongs to C and C++, and it is the layer Rust is now taking over. Python owns the workshop; it never owned the screen.

The library everything stands on

Just van Rossum, co-founder of the Letterror studio, started fontTools in 1999. Its founding idea was TTX: decompile a binary font into XML, a text file you can read, search, and edit, then compile it back with no loss. A font stopped being an opaque binary and became data a programmer could work with. Everything since follows from that move.

The library nearly stalled in the 2000s, then Google adopted it for font production in 2013. Behdad Esfahbod’s fork became the main line, and development has run continuously since, today led in commit counts by Esfahbod and Cosimo Lupo, with contributors from major software companies and type foundries. fontTools now reads and writes every OpenType table, subsets, merges, and builds variable fonts. It is MIT licensed and sits at over 5,300 GitHub stars, small numbers next to what comes below.

The 189 million download asterisk

By one measure, fontTools is not just popular, it is planetary: about 189 million downloads from PyPI, Python’s package registry, in the last month alone (pypistats, mid-October 2026), running at roughly six million a day. Almost no font tooling in history has been installed that often.

There is an asterisk, and it is the most interesting fact in this post. fontTools is a required dependency of matplotlib, the charting library half the scientific world uses: its own dependency list carries “fontTools >= 4.28.2” as required, not optional. Matplotlib uses it to subset and embed fonts when exporting charts as PDF or PostScript. So fontTools rides along with effectively every matplotlib install and test run on Earth. The download crown is real, but much of it is inherited from a plotting library, not earned at a type designer’s desk. Even after the discount, the professional layer underneath is genuinely Python, as the next section shows.

How a font gets built in 2026

Follow a new Google Fonts release backwards and the line is Python end to end. Sources arrive as .glyphs, .ufo, or .designspace files. fontmake compiles them into .otf and .ttf binaries, static instances and variable fonts alike; it has been the pipeline’s front end since its repository appeared in December 2015. gftools, a few hundred utility scripts, wraps the line: packaging, fixing, comparing, onboarding. Before anything ships, fontbakery runs the quality gate: hundreds of checks mapped to the OpenType specification and Google Fonts’ requirements. Dave Crossland started it in 2013 to speed up onboarding; Google Fonts’ own contributor guide calls it the project’s primary quality assurance tool.

The same pattern holds outside Google. The UFO source format fontmake consumes came from van Rossum, Erik van Blokland, and Tal Leming; the RoboFont editor and the DrawBot proofing tool are Python through and through. Adobe’s AFDKO pairs a C core with a substantial Python layer, and FontForge, a C program, embeds Python as its scripting language. Wherever a human builds a font with code nearby, the code is usually Python.

2016: variable fonts launched on Python tools

The strongest proof is a date: September 14, 2016, at the ATypI conference in Warsaw, where Microsoft, Adobe, Apple, and Google jointly announced OpenType Font Variations, the variable fonts now everywhere. Each company brought one piece. In Google’s own account, Microsoft did the specification work, Apple brought its existing TrueType GX technology, Adobe rebuilt its CFF format as CFF2, and Google brought “the tools and testing.” Concretely, Google had implemented most of the specification in fontTools before the announcement, and updated the fontmake pipeline so variable fonts could be built from the usual source formats. The defining font feature of the last decade did not just support Python tooling; it shipped on it. fontTools’ varLib package still builds variable fonts from designspace files today.

What Python does not do

The boundary is sharp. Shaping and rasterizing, the work of turning text into pixels sixty times a second, stayed native: HarfBuzz and FreeType in C and C++, DirectWrite and CoreText on the platforms. Google’s 2016 post states the split without embarrassment: Python built the tools, C++ updated the runtime. Even hinting sits outside: ttfautohint, the standard auto-hinter, is a compiled FreeType-project tool.

And the workshop itself is where the pressure now lands. fontbakery’s own README points readers to Fontspector, its Rust port, and Google’s compiler roadmap replaces fontmake with fontc, the subject of our Rust companion piece. The two flagship Python jobs, checking fonts and compiling them, are exactly the two Rust is coming for. Python’s reign over font production is a decade deep and nowhere near over, but for the first time it has a successor in the building.