In the beginning of digital outline fonts, people were not quite sure whether the line being drawn was opaque or transparent.
In analog type development, the punchcutter (and later the letter drawer, whose work drove punchcutting machinery) first created a transparent (or white) line around the opaque (or black), and then cut away what would be white, leaving the punch ready to make impressions in softer metal, called matrices, into which lead could be poured to make printable letters.
With input from the type industry, drawing the boundary with the outline defined as transparent (unless the user decided to “stroke” it) was carried into the first generation of digital font tools, from the mid-1970s to today. Along the way, however, Adobe tried two changes. The first attempt, before the initial release of PostScript, consisted in drawing the contour black by default, in an effort to avoid missing pixels (aka “dropouts”) on overly light type features at small sizes.
Red: default transparent boundary. Grey: default fill.
After one look at these fonts, realizing that the font libraries of the type industry would be useless with this kind of technology, Jonathan Seybold labeled them “dipped in chocolate.” Tasty as that sounds, when PostScript laser printers and typesetters ultimately materialized, almost everyone was concerned with how much darker laser printer was than typesetting.
Without Seybold's comment, not only would proofing and printing not match, but also font libraries would have needed to be redesigned; and of course hinting would probably not have existed as it came to be, if at all. Seybold's comment drove the need for another method to ensure opaque continuity—i.e., no dropouts in low-resolution letters —leading to both PostScript hinting and the TrueType instruction language.
TrueType also set out to solve the second change Adobe introduced, which goes back to cave paintings. Back then, artists learned that painting two opaque shapes on top of each other creates one opaque space that is the sum of the two. PostScript drawing worked—and works—this way. PostScript font output, though, had a bug that turned one opaque shape into four opaque shapes with a white (not transparent or opaque) hole in the middle.
Each one of these overlapping strokes has three possible options. In TrueType, on the left, strokes are allowed to overlap. The digital outline has left metal, wood, and film type behind, and defines the strokes more closely to the written or painted forms. On the right, you see what Adobe PostScript type technology has required for the last twenty-five years: the same continuous lines as metal, wood, and film type, ignorant of the overlaps. In the middle, you see what happens when a TrueType font is rendered by some Adobe PostScript devices. Also note that the TrueType example on the left has one-third fewer points than the PostScript font on the right.
Despite Apple and Microsoft supporting overlapping contours, the persistent lack of interoperability presented by this Adobe bug forced the TrueType font format’s owners, and most font developers, to produce fonts compatible with the bug and remove overlaps by adding points that most rasterizers already knew were there. Handling overlapping contours in type is probably the biggest advance in contour definition since the digital outline itself.
It breaks the contours away from their metal and film adherence to a rigid tracing of the opaque/transparent boundary, which is useful in static fonts, but not in digital fonts. That’s something we need today, because fonts need to keep the file size small enough for easy mobility while delivering all of the typographic features needed to size larger and smaller, to scale for various resolutions, to bend in hinting sometimes along the way, and to flow freely within a glyph, now that there are variations. The file(s) size required to carry a family of weights, widths, and optical sizes to a mobile user is very large, compared to the file() size of a variable font that contains three axes, for size, weight, and width.
The OpenType 1.8 font specification follows the TrueType specification, allowing overlapping contours. Nothing in the specification prevents developers from continuing to remove overlaps, if that kind of added complexity is necessary to the design of the font, or just because they feel like it. But for some who draw complex scripts (and for some design classes of all scripts), and for anyone who hints fonts and knows that some glyphs are nearly impossible to hint with the overlaps removed, removing this complexity is important. Everyone benefits from fonts that are smaller files—faster to upload, download, and render.
Keep watching this spot to see if it remains opaque, so we can go on to other basic topics, like x ’n’ y.
