On-Chain Font
This post is about condensing font files to store them on-chain. Click here to skip to the guide.
I enjoy fully on-chain projects for many reasons:
- strongest guarantees of transparency, permanence, and immutability;
- native composition with anything else on-chain and dynamicism;
- constraint-driven creativity and innovation.
Every implementation detail requires more thought because everything is costlier and harder to do on-chain, and every design choice is made more deliberately because it's supposed to live forever.
I've experienced this while building all of my fully on-chain projects (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), and one of the most common tasks was to include font files fully on-chain for accurate and consistent rendering of text across all clients.
If font files aren't included on-chain, clients have to select fallback fonts, and the guarantee of accurate rendering is destroyed. Similarly, if font files are loaded in via external dependencies (e.g. Google Fonts), the transparency/permanence/immutability guarantees are greatly weakened.
The challenge is that font files can be quite large (>100 KB), and storing them on-chain can be expensive. Luckily, depending on your usecase, you can usually reduce this by 95+% to just 2-4 KB with a few optimizations.
Guide
If you're looking to store entire font files on-chain (i.e. all glyphs), this guide is probably useless.
Storing ~100 KB on-chain isn't prohibitively expensive—it's been done before, even on Ethereum mainnet.
You could probably even get by with the most naive route: divide up the font file into many smaller parts, store them all to storage, then read them from storage.
More modern approaches of storing large files use the SSTORE2 pattern, which "stores" and reads data as nonsensical contract bytecode because after some point, deploying and reading data as bytecode becomes much cheaper than the corresponding number of SSTORE/SLOADs.
At 24 KB per contract, you only need a few shards, and even if you need more, tools like EthFS make it manageable.
If you don't need the entire font file, which is true most of the time, this is not worth doing. It'll cost more money and time, have worse DX of deploying/reading from multiple contracts, and bloat your final output.
The key realization of this guide is that font files implement paths for many glyphs, and most of the time, a project only requires a very small fraction of them. Thus, by condensing the font down to just the glyphs you need, you can greatly reduce the necessary font file's size.
Selecting the glyphs
Once you have a font you want to use, the first step is to determine the domain of characters that will be displayed with that font. For example, suppose we want to make an NFT that displays "fiveoutofnine" and the first 8 digits of the minter's checksummed address in Fira Code, something like:
Even though there's a dynamic text component, we only need the 29 characters present in "fiveoutofnine", "0x", and lowercase/uppercase hexadecimal digits (with duplicates removed):
Let's write their unicode codes to a file named glyphs.txt with the following script:
Even on the web, it's common for font registries like Google Fonts to require subsets (e.g. latin) to be specified to only import necessary ranges of characters.
Condensing the font
Next, install fonttools and run the following command to generate the condensed font file:
Make sure to run the command on a font file with a specified weight, rather than the variable weight version.
You can also optionally convert the font file into the WOFF2 format. It has good browser support and usually yields a further ~65% size reduction. I recommend using an online converter such as this one.
With this, we go from 184.1 KB to 3.4 KB—a 98.2% reduction!
Using the font
The easiest way to use the font on-chain is to base-64 encode it, so it can be used inline (e.g. inside some SVG source):
This encoding increases the size by ~34% (between ).
Then, you can use the font inside some SVG as follows: