I've been trying to stay away from webfonts as much as I can. IMO they are not worth the performance complications. Font loaders, FOUT, yadda-yadda. But... it happens.
Story time
While showing off another one of my music theory exercises to my prof, he mentioned it would be nice to be able to tell v from V in the Roman Numeral Analysis. Roman capital numbers like I, V, IV, VII etc are best written out with lines on top and bottom to avoid any confusion between upper and lower case.
"No problem," I thought, "there should be a Unicode symbol for Roman V I can use". Only I couldn't find any. Then I looked for fonts I can use... nish! But, but... there must exist a music font (or 10). Nope.
Luckily, my last semester's prof has started working on a music font. Yey! Not complete yet, but it had the V and I.
A new font subset
The lowly byte-counter that I sometimes am, I thought I should subset the font to only use the four characters I want: i, v, I and V.
I found an app called Glyphs with a 30 day trial. I deleted all the characters except the 4 I need. Exported to WOFF because this is the new and shiny web font format. Well, WOFF2 is newer and shinier, but not as well supported yet.
(BTW, the exporting was failing because of some missing "features" of the font, but I managed to find where these features are and delete them all)
Maybe because the option to export OTF font was just there, or maybe I was blaming the WOFF for the missing "features" that were failing the export, on a whim I exported to OTF too.
WOFF is smaller, right?
WOFF is a compressed format. All other formats should be gzipped when served. So WOFF should always win when comparing disk file sizes, right? Wrong, it turns out, at least in this mini-fontfile case.
- OTF: 2,628 bytes (1749 bytes after default Apache gzip setting, 6 maybe?)
- WOFF: 3,924 bytes (already zipped)
Well, so much for the new and shiny, I thought. But wait. I remembered using a random online tool to convert OTF to WOFF. Not sure what tool they use behind the scenes. Anyway, tried it.
WOFF came out 2,192 bytes.
OK, better. Not as great as OTF zipped, but better unzipped.
Searched some more - a JavaScript tool came up. Nice.
WOFF came out 1,988 bytes.
Winner?
At this point I was ready to declare the JS tool a winner. But then I tried all these other fonts I converted some time ago, 12 variants of the same font really.
- OTF: 1.8MB
- OTF2WOFF: 479KB
- WOFF.JS: 679KB
So the woff.js is not a winner after all. No clear winner really.
There's a need
What have we learned from a random sample of 12 usable font files and one kinda contrived font with 4 characters only? That there's no clear winner when it comes to woff encoders. And we need one. In this day and age there should exist a tool (or 5) we run as part of our favorite build tool, just like we do for images.
If you know of one, or better yet, use one, please hit me.
Jeremy Wagner†pointed out Ilya's article that mentions a python tool. Didn't try it (setup look involved), but looks promising.
Comments? Feedback? Find me on Twitter, Mastodon, Bluesky, LinkedIn, Threads
