2025Q2 Fonts Quarterly
Optimizing mega variable-fonts and introducing HarfRust
behdad
July 31, 2025
FreeType<—>HarfBuzz circular build dependency finally resolved
Streamlined synthetic bold/slant in hb_font_t
Faster HarfBuzz test suite runs
Optimizing mega variable-fonts
TL;DR
The quarter saw lots of shaping and other optimizations, build system improvements, documentation, and last but not least, devising a path forward to officially bring HarfBuzz to the Rust ecosystem.
HarfBuzz improvements
FreeType<—>HarfBuzz circular build dependency finally resolved
For many years now, building FreeType and HarfBuzz with their full features enabled, introduced a catch-22: a circular dependency of each package on the other. The issue had collected several “me too”s from DIY Linux builders to casual developers to distro packages.
I finally implemented a solution in FreeType, to provide an option to build without HarfBuzz present, and load HarfBuzz dynamically at runtime. This seemed to have satisfied the users.
COLRv1 painting improvements
The COLRv1 color font format has a requirement that each glyph’s paint graph has to be bounded. This is necessary for the shape to make any sense. You can’t paint the entire page from a glyph. So far so good.
But the spec goes out of its way, to unnecessarily restrict what a compliant client must do if the font has an unbounded paint graph. Ie. when the font is broken: paint nothing. It requires that nothing be painted. From an implementation point of view, this is a burden, since the client now has to do a first pass over the paint graph to determine whether it is bounded, before proceeding to any drawing. It cannot just start drawing and give up when an unbounded paint operation is detected.
So I filed an issue to fix this in the spec. I’m not holding my breath though. In the meantime, HarfBuzz seems to be the only major client to respect this requirement. We do that to make it easier on the client’s graphics library.
That said, the implementation was slower than it could be. So I sped it up significantly.
Streamlined synthetic bold/slant in hb_font_t
The HarfBuzz font layer provides synthetic bold and slant, like many other font libraries do. The support for this was very primitive and inconsistent across different font backends. This has been fixed now, and all font backends, including client-custom ones, will benefit from consistent support for those features. Moreover, glyph extents are computed correctly for synthetic fonts.
Faster HarfBuzz test suite runs
The HarfBuzz test suite once used to be fast. As we gathered more and more tests over the years, it had become slow, taking more than 30 seconds to run on my development machines. This slowed down my development edit-build-test cycle enough to look into improving it.
I switched the test suite to use the TAP protocol, reduced redundant subset tests, batched the fuzzing tests, and used hb-shape’s batch mode to run all shaping tests. The latter paid off most. 6989 subtests pass in less than 1.5 seconds!
The result is that the test suite runs in under 3 seconds, from over 30 seconds before. Not bad.
HarfBuzz Study: Subsetter
Continuing the HarfBuzz Study deep dives into HarfBuzz’s internals, Garret and I wrote one on the subsetter.
You can find links to all the previous writeups in the HarfBuzz Study series here.
Optimizing mega variable-fonts
GoogleSansFlex is a font shipped with recent Android. It is a variable font with six variation axes and a whopping ~260 masters. The Android team was not happy with the speed of loading glyph shapes from this font, so I spent some time optimizing it in HarfBuzz and FreeType, and Chad Brokaw optimized fontations’ Skrifa. All improvements have been merged into the respective projects. Report.
The case of the no-HVAR recommendation on Android
As part of addressing the performance issues on Android, I recommended that they ship the font with the HVAR font table removed. This is a curious recommendation which demands explanation.
It is to work around a FreeType deficiency. The HVAR table was added as a cache of the advance-width variations, such that for layout purposes, one wouldn't need to process the gvar table to get the advance-width variations. But FreeType does both: load glyph outline using gvar, but then get the glyph advance from HVAR. This is a waste of time and effort. It will be fixed at some point. The suggested font change is an interim solution. We still recommend shipping fonts with HVAR for better performance overall across various implementations.
Boring Expansion proposals
The boring-expansion set of proposals made forward progress in the ISO standardization pipeline. Our only comment from last December was approved by the committee. This means that “ISO-IEC DIS 14496-22 (Ed 5), Information technology — Coding of audio-visual objects — Part 22- Open font format” is currently being prepared for its eight-week ballot as an ISO FDIS (Final Draft International Standard), and unless there are further substantive changes (unlikely), it will be released as an international standard (🤞) early next year. At that point, the Boring Expansions will be fully standardized and should trickle down into the OpenType standard and other implementations over time.
A Rusty way forward
It is news to nobody that the industry has been moving font rendering to Rust. Google has been leading the most ambitious Open Source effort with Oxidize.
In shaping land, there have been many attempts to come up with a HarfBuzz replacement in pure Rust, with Rustybuzz being the front-running contender for the recent past.
After considering the problem space from various angles, we came to the conclusion that building a fork of Rustybuzz to work with Oxidize’s fontations set of crates is our preferred solution forward.
You can read the plan in: HarfBuzz Study: Introducing HarfRust.
As part of bringing HarfRust up to date with the latest HarfBuzz, and improving it in general, I added Rust code output generation support to the table-packer tool packtab. You can read more about packtab and the problem it solves in: HarfBuzz Study: PackTab.
Acknowledgements
I like to thank Google Fonts for financially supporting my work. I am grateful for the help of the following people: HarfBuzz maintainer Khaled Hosny, FreeType maintainer Werner Lemberg, Liam Quin, Google Fonts: Dave Crossland, Rod Sheeter, Chad Brokaw, and Garret Rieger. RazrFalcon and Laurenz Stampfl for Rustybuzz. And the memory of Chris Simpkins.