But... can I make it an even smaller font?
You are viewing this page with JavaSCript disabled; the work on this page<br>was done in order to integrate it into the<br>Processing.js javascript library, so<br>if you want to see the final result, you'll have to enable javascript.
A story about creating a 520 byte spec-compliant font, encoded as a 298<br>character javascript function that generates its Base 64 equivalence<br>string for use on a webpage.
Let's get started
Chances are you already know what a font is. It's something you select in<br>a word processor, or text editor if you're hard core, and write your text<br>in. They're the things that make letters look different in documents, and<br>in today's world, the web. For the longest time the web's been a bit of a<br>limited font game, but in recent years "web fonts" have become more and<br>more popular. The ability to load the font YOU want to use, rather than<br>that "Times" font, or just "serif", has won a lot of people over (fun<br>fact: IE's been able to do this since version 4. I know, who would have<br>guessed, eh?)
What you probably don't know is that fonts are complicated>.<br>However you think a font works: no, it's way more complicated than that.<br>No really, it's so much more complicated than what you're thinking<br>of.
There are a number of common formats, and none of them are what you'd<br>describe as "easy to read". In order to make fonts small, the data inside<br>a font has been encoded in most spectacularly space-saving ways, after<br>which a million and one features were tacked on top because different<br>groups needed additional functionality from fonts. This includes things<br>like right to left writing, subroutines/substitutions so that<br>compositional characters (such as nearly all CJK characters) take up less<br>space, vertical metrics for Asian scripts, substitution pairs for letter<br>combinations, which is the backbone for written Arabian, the list goes on<br>and on. If you are thinking about going into fonts, from a programming<br>perspective, rather than a design perspective, I tip my hat to you; you<br>are in for a rough ride.
However, should you preservere, you might end up where I am today (2026<br>edit: or, where I was over a decade ago of course =): a head full of<br>knowledge about things most people stay away from, and a sudden<br>realisation that a thing I was trying to do is something that might<br>actually be possible... I need the smallest possible OpenType font avaible<br>so I can embed it into a web page in order to do font load detection...<br>can I just make one?
(Both Fore and aftshadowing: that "just" is doing some<br>seriously heavy lifting)
Some back story
I've written my own OpenType font parsers, with TrueType and Type2<br>support, and while writing those I've learned many things about font<br>technologies. I used them for playing around with CJK character<br>composition, text composition on web canvas, and a bunch of other things<br>like path extraction and optimization that eventually ended up (in a very<br>round-about way) becoming my<br>Primer on Bézier Curves.
Then, after a while, fonts slowly sank back into the background until one<br>day, while talking about log visualisations, someone mentioned using the<br>Processing programming language.<br>Having never heard of it, I looked it up, discovered it was about the best<br>programming language in the world for quick and easy visualisations, and<br>then dicovered it had a javascript port. I was hooked.
I started helping out with<br>Processing.js (which I ended up<br>playing a significant role in, and ended up retiring in December 2018. RIP<br>Processing.js, you still occupy a huge part of my heart) and after a while<br>I realised I could exploit the web's various technologies to mix<br>visualisation in browsers with my font parsers in the backend for a much<br>more playful font interaction. And, of course (as these things go) I<br>became a dev for Pjs and started looking more and more into its font<br>implementations for every font bug report we received. After we released<br>v1.2.3, font handling desperately needed a full rewrite and I found myself<br>back in a "fixing font things" position. And that brings us to today.<br>(2026 edit: well, over a decade ago now since writing this, but it's still<br>a worthwhile investigative exercise in the current browser landscape)
Today (so, read: "over a decade ago" =), I find myself in the position<br>that we need to wait with starting a Processing "sketch" (the Processing<br>name for a program) on a web page until all fonts that should be<br>preloaded, have finished preloading. This means we can't just wait for the<br>browser to finished downloading them, but we also have to wait for the<br>browser to finish loading them into memory for styling text on a page. If<br>you think that waiting for the download should be enough: fonts are<br>relatively big, complicated things. It can take a few hundred milliseconds<br>between a font being done downloading and being fully loaded in memory if<br>it's a few hundred kb, but bigger, professional fonts in four different<br>styles means it can actually take...