Adobe Blank Redux
As discussed in our March 28, 2013 article, Adobe Blank was recently released as a open source special-purpose OpenType font that helps to solve the FOUT (Flash Of Unstyled Text) problem.
The version that was initially released was approximately 80K in size, and included 257 glyphs, 256 of which were functional in the sense that they are mapped from 1,111,998 Unicode code points, though they are intentionally non-spacing and non-marking. I further analyzed the tables, and found a way to trim the size further by increasing the number of glyphs to 2,049, 2,048 of which are functional. The size is now a more modest 32K.
The table that was included in the original article is repeated below, with the data for the 2,049-glyph font added in:
| Number of Glyphs | CFF | cmap | hmtx | vmtx |
|---|---|---|---|---|
| 2 | 259 bytes | >13MB (estimated) | 8 bytes | 6 bytes |
| 257 | 1,081 bytes | 54,228 bytes | 518 bytes | 516 bytes |
| 2,049 | 6,451 bytes | 6,880 bytes | 4,102 bytes | 4,100 bytes |
| 65,535 | 262,419 bytes | 328 bytes | 131,074 bytes | 131,072 bytes |
Interestingly, the largest table is now the ‘name‘ table, which is 10,066 bytes. This is primarily due to the inclusion of its full open source license as its name.ID=13 (License Description) string.
In closing, I am also thinking to jettison its vertical tables, meaning ‘VORG‘, ‘vhea‘, and ‘vmtx‘, which will reduce the size a further 4K or so, but I’ll leave that for another day.
P.S. As of earlier this afternoon, the Adobe Blank sources are now available on GitHub.
2 Responses
Comments are closed.
It seems the sizes mentioned are for the OTF version? Wouldn’t it be more relevant to compare and the figures after conversion to WOFF? That is, if size is relevant only for use as webfont.
Ken,
I noticed a css file on sourceforge. I haven’t been able to find browser compatibility of base64 encodes anywhere. Is the compatibility better than otf?