Adobe Blank: The Typeface Design

By Dr Ken Lunde, Janitor, Spirits of Christmas Past

This is the image that was used in the article entitled “Adobe Blank VF & Friends” (2019)

Bluntly speaking, although I have nearly three decades of experience developing East Asian fonts, mainly during my 28+ years of tenure at Adobe, I am not a typeface designer. Never was—and at my age—never will be. This is not a confession, but rather an undisputed fact.

My 28+ Years of #AdobeLife

Of course, I have created my fair share of new glyphs, or modified existing ones, but that was to supplement or adjust an existing typeface design. When I developed the additional Heisei (平成 heisei) fonts, beyond Heisei Mincho W3 (平成明朝 W3) and Heisei Kaku Gothic W5 (平成各ゴシック W5) that were the first two, I did precisely that in the late 1990s in order to bring the remaining weights of the Heisei Mincho and Heisei Kaku Gothic families, along with the two weights of the Heisei Maru Gothic (平成丸ゴシック) family, up to the Adobe-Japan1-1 glyph repertoire.

Technically speaking, however, I am a typeface designer…

Adobe Blank

Let me introduce to you Adobe Blank, my one and only typeface design whose glyphs are impervious to any critique whatsoever. Ignoring the mandatory .notdef glyph, below is a complete rendering of the glyphs for its 1,111,998 Unicode code points, which are shown in their entirety between the double quotes:

“”

This is not a joke. I repeat, this is not a joke!

Some background would be helpful, I suppose…

It was in early 2013 that an Adobe colleague, Joel Brandt, requested that I develop a special-purpose font that 1) supported all Unicode code points; and 2) mapped them to a non-spacing and non-marking glyph. In other words, blanks.

The first Adobe Blank prototype was born on 2013-01-16. Below are its birth statistics:

• Developed as a CID-keyed OpenType/CFF font based on the special-purpose Adobe-Identity-0 ROS (Registry, Ordering, and Supplement)
• Supported all 1,111,998 Unicode code points, which excluded the 2,048 High and Low Surrogates plus the 66 noncharacters
• Included 257 glyphs (GIDs 0 through 256)

The original intent, as Joel described to me, was to use Adobe Blank in Brackets and Adobe Edge Web Fonts for the following two specific purposes:

• Invoking Adobe Blank, as a temporary measure, circumvented the invoking of OS- or application-level font-fallback before the intended web font could be rendered. You’ve heard of the acronym FOUT, right? It stands for Flash Of Unstyled Text, which may occur while a web font is loading.
• Related to the above, using Adobe Blank allowed one to detect when a web font is actually loaded, which was arguably a hack to overcome a limitation in CSS

I also planned to make Adobe Blank available as open source, and it was first released on 2013-03-26.

As a professional font developer, there was an interesting technical hurdle that I faced while developing Adobe Blank, which involved two extremes:

• One extreme was that there was a single functional glyph, which meant that the CFF (Compact Font Format) table could potentially include only the mandatory .notdef glyph as GID+0 (Glyph ID 0) and the functional non-spacing and non-marking glyph as GID+1 (Glyph ID 1)
• The other extreme was that I needed to map 1,111,998 code points to the same glyph

However, if I were to use a Format 12 (Segmented coverage) cmap subtable, which is the most broadly supported subtable format that supports all Unicode code points, it would necessarily include 1,111,998 individual mappings to GID+1. I calculated that while the CFF table would be approximately 250 bytes, the cmap table, on the other hand, would be over 13MB! Consider the following two additional scenarios that involve different numbers of glyphs:

• When I increased the number of glyphs to 257, meaning that ranges of 256 contiguous Unicode code points could map to this range of 256 GIDs, the CFF table would grow to approximately 1K, but the cmap table would still be over 50K.
• When I further increased the number of glyphs to 65,535, which is the architectural limit for CID-keyed OpenType/CFF fonts, the CFF table grew to 250K, but the cmap table was reduced to a little over 300 bytes. However, the required hmtx (Horizontal Metrics) table grew to over 130K. For reference, the hmtx table size of the two- and 257-glyph versions were only 8 and 516 bytes, respectively.

In other words, when dealing with a single functional glyph and a very large number of mappings, the number of actual glyphs influences the size of the following three tables: CFF, cmap, and hmtx.

I finally settled on 2,049 glyphs, with GIDs 1 through 2048 being the functional ones for mapping ranges of 2,048 Unicode code points to them, which struck the best overall balance between the number of glyphs and the size of the three tables:

• The CFF table was barely over 6K
• The cmap table was also barely over 6K
• The hmtx table was barely over 4K

The overall footprint was less than 20K. The only other table of significant size was the name (Naming) table, which was 1.5K due to including text for the open source license.

Several articles were published about Adobe Blank in 2013, such as by The H Open, Inquisitr, TechCrunch, TechCrunch Japan (Japanese), and Typedia.

Adobe Blank 2

After two years, I apparently decided that I could do better, and Adobe Blank 2 was subsequently born on 2015-04-01. Despite it being April 1st, Adobe Blank 2 was not a joke, though it was a fitting date on which to release such a font due to its unique characteristics.

This is the image that was used in the article entitled “1,111,998 to 1 → Adobe Blank 2” (2015)

Adobe Blank 2 takes the idea of Adobe Blank one step further by using a non-conventional but highly-efficient cmap subtable format, Format 13 (Many-to-one range mappings), which is specifically designed to map large ranges of code points to a single glyph. Last Resort is an example of a font that also benefits from this highly-efficient cmap subtable format.

As a result of using the Format 13 cmap subtable, the number of functional glyphs was reduced to only one, specifically GID+1. Of course, GID+0 is still present, and serves as the mandatory .notdef glyph.

While the latest version of ttx (aka fonttools) allows all 1,111,998 individual mappings to be specified in the XML that is compiled, at the time Adobe Blank 2 was first developed, the Format 13 subtable structure needed to be specified by hand as shown below, which was inspired by the tofudetector project, but was specifically tailored to exclude the 2,048 High and Low Surrogates plus the 66 noncharacters:

<?xml version="1.0" encoding="utf-8"?>
<ttFont sfntVersion="OTTO" ttLibVersion="2.4">

  <cmap ERROR=""> <!-- Use raw="1" for newer versions of ttx -->
    <!-- Hand-coded Format 13 mapping: all of Unicode to GID+1 -->
    <hexdata>
      0000 0001 <!-- version numTables -->
        0003 000A <!-- platformID encodingID -->
        0000000C  <!-- offset -->
          000D 0000 <!-- format reserved -->
          000000F4  <!-- length -->
          00000000  <!-- language -->
          00000013  <!-- nGroups -->
            00000000  <!-- startCharCode -->
            0000D7FF  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            0000E000  <!-- startCharCode -->
            0000FDCF  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            0000FDF0  <!-- startCharCode -->
            0000FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00010000  <!-- startCharCode -->
            0001FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00020000  <!-- startCharCode -->
            0002FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00030000  <!-- startCharCode -->
            0003FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00040000  <!-- startCharCode -->
            0004FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00050000  <!-- startCharCode -->
            0005FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00060000  <!-- startCharCode -->
            0006FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00070000  <!-- startCharCode -->
            0007FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00080000  <!-- startCharCode -->
            0008FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00090000  <!-- startCharCode -->
            0009FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            000A0000  <!-- startCharCode -->
            000AFFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            000B0000  <!-- startCharCode -->
            000BFFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            000C0000  <!-- startCharCode -->
            000CFFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            000D0000  <!-- startCharCode -->
            000DFFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            000E0000  <!-- startCharCode -->
            000EFFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            000F0000  <!-- startCharCode -->
            000FFFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
            00100000  <!-- startCharCode -->
            0010FFFD  <!-- endCharCode -->
            00000001  <!-- glyphID -->
    </hexdata>
  </cmap>

</ttFont>

The main benefit of using the Format 13 cmap subtable, of course, is that only a single functional glyph is necessary, which results in considerably smaller CFF, cmap, and hmtx tables, shrinking the size of the font to barely over 2K, which literally decimated the size of the original Adobe Blank font. Interestingly, more than 50% of its file size is attributed to its name table, mainly due to the length of the name.ID=13 (License Description) string, which is 662 bytes or nearly one-third the size of the font:

This Font Software is licensed under the SIL Open Font License, Version 1.1. This Font Software is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the SIL Open Font License for the specific language, permissions and limitations governing your use of this Font Software.

Be aware that the Format 13 cmap subtable format is not broadly supported, which limits the extent to which Adobe Blank 2 can be deployed. For example, most Microsoft and Adobe apps do not support fonts that include this cmap subtable format.

In closing this section, I would like to be on record to state that the name Adobe Blank 2 was derived from it being a version of Adobe Blank that includes only “2” glyphs.

Adobe Blank VF & Friends

Near the end of my tenure at Adobe, I decided to push the concept of Adobe Blank even further by developing a Variable Font version. Well, versions, as I will explain. Adobe Blank VF & Friends is an open source project that includes a total of four Variable Fonts that were inspired by Adobe Blank and Adobe Blank 2.

The idea behind Adobe Blank VF and its “friends” is relatively simple: Adobe Blank and Adobe Blank 2 distinguished themselves by including only non-spacing and non-marking functional glyphs. The Variable Font versions preserve the non-spacing and non-marking functional glyphs as the default values for their two design-variation axes, wdth (Width) and HGHT (Height).

The HGHT design-variation axis tag is all-uppercase, because it is unregistered Only registered tags are all-lowercase.

Both design-variation axes support the range zero (0) through 1000, with zero being the default value, because it is non-spacing. The value 1000 represents full-width or a 1000-unit Em.

As a side note, I would like to point out that these iterations of Adobe Blank are not CID-keyed, and cannot be, because the notion of CID-keyed is irrelevant for CFF2-based Variable Fonts.

As one could expect, the non-marking nature of Adobe Blank VF made testing somewhat challenging, particularly when the design-variation axes function perpendicular to the writing direction, so a companion marking version, named Adobe Black VF, was developed.

The wdth design-variation axis is expected to behave as follows in horizontal and vertical writing:

• Horizontal—Glyphs and their horizontal advances expand along the X-axis to the right from the horizontal origin as the value increases, from the default value of zero (non-spacing) to 1000 (full-width).
• Vertical—Glyphs expand along the X-axis from the center of the em-box to its left and right edges as the value increases, from the default value of zero to 1000. This design-variation axis doesn’t influence the horizontal advance.

Next, the HGHT design-variation axis is expected to behave as follows in horizontal and vertical writing:

• Horizontal — Glyphs expand along the Y-axis from the center of the em-box to its top and bottom edges as the value increases, from the default value of zero to 1000. This design-variation axis doesn’t influence the vertical advance.
• Vertical — Glyphs and their vertical advances expand along the Y-axis downward from the vertical origin as the value increases, from the default value of zero (non-spacing) to 1000 (full-width).

The five-frame animated image below illustrates how the two design-variation axes are expected to behave in horizontal writing, starting from axis values that are zero, alternately incrementing wdth then HGHT to 500 then to 1000 (the Adobe Black VF glyph is surrounded by 1000×1000 cyan-colored boxes to better demonstrate the varying horizontal advances):

Likewise, the five-frame animated image below illustrates the same, but in vertical writing, again starting from design-variation axis values that are zero, but instead alternately incrementing HGHT then wdth to 500 then to 1000:

Of course, I also developed versions that use the highly-efficient Format 13 cmap subtable, aptly named Adobe Blank 2 VF and Adobe Black 2 VF, along with TrueType versions of all of them.

Adobe Blank VF and Adobe Black VF are also featured on Nick Sherman’s valuable Variable Fonts website.

Knowing full well that I am no longer associated with Adobe Blank and its offspring, I sometimes wonder what other possibilities are in store for this infamous typeface that I ushered into this world several years ago…

About the Author

Dr Ken Lunde worked at Adobe for over twenty-eight years — from 1991-07-01 to 2019-10-18 — specializing in CJKV Type Development, meaning that he architected and developed fonts for East Asian typefaces, along with the standards and specifications on which they are based. He architected and developed the Adobe-branded “Source Han” (Source Han Sans, Source Han Serif, and Source Han Mono) and Google-branded “Noto CJK” (Noto Sans CJK and Noto Serif CJK) open source Pan-CJK typeface families that were released in 2014, 2017, and 2019, is the author of CJKV Information Processing Second Edition (O’Reilly Media, 2009), and published over 300 articles on Adobe’s now-static CJK Type Blog. Ken earned BA (1987), MA (1988), and PhD (1994) degrees in linguistics from The University of Wisconsin-Madison, served as Adobe’s representative to the Unicode Consortium since 2006, was Adobe’s primary representative from 2015 until 2019, serves as Unicode’s IVD (Ideographic Variation Database) Registrar, attends UTC and IRG meetings, participates in the Unicode Editorial Committee, became an individual Unicode Life Member in 2018, received the 2018 Unicode Bulldog Award, was a Unicode Technical Director from 2018 to 2020, became a Vice-Chair of the Emoji Subcommittee in 2019, published UTN #43 (Unihan Database Property “kStrange”) in 2020, and became the Chair of the CJK & Unihan Group in 2021. He and his wife, Hitomi, are proud owners of a His & Hers pair of acceleration-boosted 2018 LR AWD Tesla Model 3 EVs.