Posted by Dr. Ken Lunde

 Comments (3)


April 3, 2013

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.


  • By Tim Ahrens - 3:33 PM on April 3, 2013  

    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.

  • By Ramanan - 11:17 PM on April 5, 2013  


    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?

  • By Beni Cherniavsky-Paskin - 4:08 PM on March 28, 2014
    In theory, base64 data support is orthogonal to format—you can embed any format but the browser has to understand it. In the real world, IE limits it to some resoursce types :-(, and I saw conflicting info on IE’s embedded font support.

    Embedded fonts can be more robust than files: mentions evil firewalls blocking font files (but not css). mentions cross-origin woes with external files.

    But if you’re concerned with wide compatibility, you probably need more than one format. At that point embedding becomes wasteful because the css is downloaded by all browsers. You probably want to embed at most one format (woff is most compact).