2025Q4 Fonts Quarterly

behdad
December 1, 2025

This report covers a shortened period of time as I was dealing with medical issues in October, and the report date of December 1st. Previous reports: Q3, Q2, Q1.

HarfBust

HarfBust is a font software puzzle that I posted publicly in September. As I was losing hope that anyone would submit a complete solution, one night in November I received an email describing a full soltuion to the puzzle by the github user gandaro, and as such they won a hoodie:

As a result, we fixed HarfBuzz and HarfRust to remove the unusual behavior and I wrote a recap to the issue.

HarfBuzz

There were a few changes worth mentioning:

Sanitizer change

Previously, HarfBuzz tried to recover from invalid font data tables (prominently the offset-based tables like GDEF/GSUB/GPOS/COLRv1). This could result in HarfBuzz hallucinating things out of thin air, as per the HarfBust puzzle above.

Now, HarfBuzz rejects invalid font data tables and does not try to sanitize them. This behavior seems to reflect what CoreText does. DirectWrite and now HarfRust instead just ignore the invalid bits of the table and process the rest.

Disable kern table for most shapers

As per community request, we disabled application of the legacy kern table to fonts using most shapers. The legacy kern table will only be applied to the default (Latin, etc), Arabic, Hebrew, and Hangul text. This avoids double-kerning in scripts that use the dist OpenType feature instead of the kern feature in GPOS to apply their kerning.

Backtrack/lookahead per-syllable matcher changes

When matching a ChainContext sequence rule against the glyph stream, in some shapers (Indic / USE family), the rules are spec’ed to apply to within the current syllable only. That is how DirectWrite works.

Back in 2015, Jonathan Kew and I had decided that it would be more expressive for the font designers, if we allow matching the backtrack & lookahead parts of the sequence across syllable boundaries. This departure from DirectWrite behavior was never reported to us as a bug.

Recently, we realized that the implementation of the above behavior was buggy and could result in unreliable application of backtrack sequence to within the syllable only, most of the times, and across syllable boundary other times.

To address the above bug, we could go different routes: depart from DirectWrite, or adopt its behavior. After extensive testing across all relevant Google Fonts families and the HarfBuzz Wikipedia text corpora for the affected scripts, we decided to adopt the DirectWrite behavior.

Details.

Mega-var-font drawing speedups

GoogleSansFlex is a variable font with ~216 masters! In Q2 I had sped up HarfBuzz drawing of it by some 40%.

Upon further inspection and profiling and many experiments, I was able to squeeze another 40% drawing time, again, with just a few minor tweaks to the code. (PRs: 1, 2, 3).

HarfRust

Updated to latest HarfBuzz changes.

GoogleSansFlex drawing perf measurements

Based on a request from Google, I measured the drawing performance of GoogleSansFlex across HarfBuzz, FreeType, and CoreText. HarfBuzz is by far the fastest, followed by FreeType, and then Apple CoreText.

The measurements informed how to deliver the fonts more efficiently, as well as leading to a 40% optimization in GoogleSansFlex’s drawing time in HarfBuzz (described earlier).

Details: GSF draw perf comparison.

beyond-64k

I started the monumental work of updating HarfBuzz to the latest beyond-64k proposal as finalizing at ISO OpenFontFormat.

The original version of my proposal was very minimal, touching just enough of the data structures to enable beyond-64k. However, during review and as a result of consensus-building, the proposal blew out of proportion, including duplication of a bunch of the essential tables (GLYF, LOCA, GVAR, HHEA, HMTX, VHEA, HMTX, MAXP, etc).

Updating HarfBuzz to the latest proposal is a tedious task, involving going through the 80-page spec diff and investigating whether it is already implemented, implemented differently, or needs implementation, and adjust accordingly. This is going to take some time, and I have made AI-assisted progress doing a fraction of it so far.

Beyond HarfBuzz, updates to FontTools will be easier in the read/write parts of the library. But support in the fonttools.merge tool or ufo2ft / fontmake will be significantly more work. Fontations / fontc stack to be evaluated with the Oxidize team in 2026.

layout-ng

I wrote and submitted a grant proposal to NLnet (EU) titled “Next-gen font format support for faster text shaping”. Regardless of acceptance, the proposal lays down the roadmap for a big chunk of my work time in 2026.

Technical proposal

1. ALGORITHMIC TRANSLATION: LINEAR RULESETS TO TRIES

   • The current OpenType layout model (designed in the late 1990s) is computationally naive. It enumerates substitution and positioning rules as linear lists, requiring the shaping engine to check hundreds or thousands of rules sequentially for every glyph.

   • The Challenge: We propose replacing this linear scanning with a Trie data structure, moving the complexity from runtime (shaping) to compile time. The algorithmic challenge is to ensure that complex, context-dependent OpenType rules—where the order of application is critical—can be losslessly distilled into a Trie without altering the visual result.

   • The Outcome: A successful implementation will drastically reduce the time complexity of shaping, while simultaneously reducing file-size by deduplicating redundant rule data.

2. SPARSE STATE MACHINE ENCODING

   • We are investigating extending the model to support state-machine logic, similar to AAT or Graphite but without their inefficiencies, to represent the rules in a much more compact way that can be processed even more efficiently.

   • The Challenge: AAT and Graphite use "dense" encoding for their state transition tables, which results in bloated font files. Our challenge is to implement a sparse encoding schema for the state transition table.

   • The Risk: There is a risk of over-engineering. A significant part of the research phase will involve evaluating whether a full state-machine model is necessary, or if a Trie-based approach covers 99% of use cases. We must determine the optimal balance to avoid recreating the complexity issues of the past.

3. SOURCE DATA COMPATIBILITY (THE "ADOBE FEATURE FILE" GAP)

   • Adoption depends on tooling. Font designers currently define the "grammar" of their fonts using the industry-standard Adobe Feature File format.

   • The Challenge: We must build a compiler capable of analyzing existing Adobe Feature Files and re-interpreting their high-level logic into our new, optimized binary tables.

   • The Constraint: Font designers should not have to learn a new language. The complexity of the new format must be completely abstracted away by the compiler (e.g., fontmake), translating their existing source data into the new, efficient structures automatically.

4. TUNABLE OPTIMIZATION PROFILES (WEB VS. OS)

   • Different deployment environments have different constraints.

   • The Challenge: A system font (stored locally on an OS) benefits from uncompressed data structures that can be memory-mapped for raw speed. A web font prioritizes transmission size over raw memory speed.

   • The Solution: We will research encodings that allow for "tunable" trade-offs. The file format should ideally support different compilation profiles, allowing a font engineer to choose between "Maximum Compression" (for web) and "Maximum Throughput" (for operating systems).

Delivarables

• Whitepaper & Specification: A proposal for the OpenType/ISO OpenFontFormat layout model, including a survey of prior art.

• Reference Implementation: Production-ready support in the HarfBuzz text shaping engine.

• Tooling: Proof-of-concept implementation in the fontmake (python) and/or fontc (rust) compiler stacks.

• Validation Suite: Test fonts representing workloads of varying complexity (e.g., Latin, Arabic, Indic).

• Performance Analysis: Empirical benchmarks demonstrating improvements in shaping speed and file-size efficiency.

• Standardization: A formal proposal submitted to the ISO OpenFontFormat working group.

PackTab

PackTab is an integer data table packer (study) that I originally wrote back in 2001. It is widely used in HarfBuzz and HarfRust to encode Unicode data efficiently.

The Parley text layout system was looking to switch from various smaller Rust crates for Unicode data to use the icu4x CodePointTrie data-structure. Based on my suggestion, Taj, one of the Parley developers, tried packing the Unicode data with PackTab instead, and saw the following improvements:

• PackTab 40kb data size compared to icu4x 70kb data size,

• PackTab 64% faster to access the Unicode properties compared to icu4x.

I wrote my thoughts about where this performance gap comes from, and suggested that PackTab should be adopted by ICU.

Logo refresh

I was looking for a logo for HarfRust, and decided to get some help from the AI image generators. A rusty surface was the background. Whereas the HarfBuzz logo is set in the Nastaliq style of Arabic script using the IranNastaliq freebie font, for HarfRust, I wanted something less curvy and more clunky and with straight lines since “rust” also means straight in Persian. We settled on Khaled Hosny’s Astrolabe font, which is based on metal engravings on astrolabes. The final result:

At that point, I decided to give the B&W HarfBuzz logo a refresh. If Rust is rusty iron, I decided that HarfBuzz’s C++ would be some kind of steel. Initially going with stainless-steel, we finally settled on Damascus steel based on Jonathan Kew’s suggestion:

While at it, we created one for uharfbuzz Python bindings:

And one for the harfbuzzjs JavaScript bindings:

Acknowledgements

I like to thank Google Fonts for financially supporting my work.