CAUTION: Some illustrations on this page are original size renditions of characters. To view these illustrations pixel-by-pixel, the way they were intended to be seen, please be sure to reset your browser’s “zoom” to 100% (pressing
“Ctrl 0” will do so in just about any of the recent browsers).
“Hinting” is a font industry term that loosely refers to “improving the appearance of small text at low resolution.” In practice, “hinting” often comes across as ad hoc adjustments called “delta hinting” to fix some pixel problems here and there—with mixed results. It’s not that “hinting” or “delta hinting” weren’t following any rules or priorities at all, at least conceptually so, but they may not always be applied consistently.
A part of the problem is that “hinters” (people doing the “hinting”) may often see only one character at a time, and only at one size, rendered by a specific font smoothing method applied to an LCD device. But like a painter alternating between focusing on the most minute details of the painting and attending to the big picture, “hinting” must address pixel problems both locally and within the context of the entire font. What may seem like picking the “lesser evil” at the level of an individual character may prove to be the “bigger evil” at the level of the font.
Therefore, my take on “hinting” is to implement sets of rules and priorities in reusable code templates, rather than trying to follow any rules or priorities in my head while fixing individual pixels on individual characters at individual sizes. In the process, as type size and device resolution decrease, fonts become more regular than designed, taking away from the artistic details of their design, simply because the size of the pixels no longer permits to render small differences. Code templates can implement strategies to equalize these small differences by consistently picking the “lesser evil” while at the same time factoring in both the small and the big picture. I’ll call this approach regularization.
Once the rules and priorities are implemented in code templates, they can be parameterized, effectively permitting to defer decisions that I cannot or do not want to preempt:
Accordingly, I’ll call this approach parameterized regularization. Conceptually, it’s that simple!
Drawing millions of pixels. On today’s computers, smart phones, or similar electronic devices, anything that gets displayed is made up of pixels—tiny little squares that can be lit in millions of colors. This works great for photos because image scientists have figured out ways to reduce megapixels from digital cameras into recognizable thumbnails on screen.
It becomes a Sisyphean task for fonts if the pixels must be drawn by hand, because it adds up to millions of pixels once arbitrary zoom percentages and different font smoothing methods are factored in.
“Coloring in” line art with pixels. Enter the outline font: an outline font contains electronic drawings of each character’s shape, made up of lines and curves called outlines. Simple math can scale the outlines (make them larger or smaller as needed) and a computer program called rasterizer can “color in” the outlines with pixels instead of drawing them by hand.
However, the outcome of this approach is often unsatisfactory (Fig 1) because the pixels on today’s screens are too large for small text sizes.
Adapting line art to large pixels. As the outlines are made smaller for rendering small text on low resolution screens, they must be simplified or even caricatured, gradually taking away from the artistic details of their design, to ensure some degree of legibility (Fig 2).
Notice how under- and overshoots, different round and straight stem weights, and eventually design contrast and entire serifs are lost in the “resolution funnel” (Fig 3).
Times New Roman becomes a “Monoline Rockwell,” but compared to the unmodified outlines the outcome remains legible.
Fig. 1: “Coloring in” the outlines with large pixels is often unsatisfactory. As the text gets smaller, there are fewer pixels for “coloring in,” some of the pixels look like the result of “chance effect,” and in extreme cases the character disintegrates altogether
Fig. 2: Simplifying the outlines, gradually making them more regular than designed, to the point where they are caricatured to the bare essentials—serif vs sans-serif
Fig. 3: Simplified outlines maintain legibility, but take away from the design. Under- and overshoots, along with different round and straight stem weights, are lost on most of the illustrated sizes, design contrast is lost on half of the sizes, and on the smallest sizes even entire serifs must be dropped—on Times New Roman
Adapting by rules and priorities. Outline simplification or regularization is the most critical part of the process. Conceptually, it follows a set of rules and priorities that stipulate conditions for different round and straight stem weights to be equalized (pixels getting too large to render their difference) or conditions for serifs to disappear (running out of available space), and similar.
Practically, these rules and priorities must be translated into computer code—in case of TrueType a tedious process in an arcane machine language.
“Delta-Hinting” vs rules and priorities. “Hinting” is a font industry term that loosely refers to “improving the appearance of small text at low resolution.” On the surface, both “hinting” and outline regularization pursue similar goals.
In practice, “hinting” often comes across as ad hoc adjustments called “delta hinting” to fix some pixel problems here and there, which may explain the shapes of some “hinted” outlines (Fig 4), and it can wreak havoc on font smoothing.
Fig. 4: So-called “delta hinting” can mangle the outlines pretty badly. While it may yield the desired pattern of black pixels, it wreaks havoc on font smoothing
Font-smoothing reduces “jaggies.” Font smoothing (anti-aliasing, gray-scaling, or subpixel rendering) helps to reduce the stair-stepped appearance (“jaggies”) of diagonal and round character parts, but it doesn’t make “hinting” obsolete. Characters rendered at unfortunate combinations of font design and text sizes can reduce parts of words to blobs of gray or lines of vibrating colors (Fig 5).
It takes “hinting” or regularization to make this legible—notably on a font designed for user interfaces on screen (Fig 6).
Fig. 5: Font smoothing without “hinting” can reduce unfortunate combinations of font design and text sizes to blobs of gray or lines of vibrating colors
Fig. 6: Adapting the outlines in the presence of font smoothing can improve the perceived sharpness of both gray-scaling and subpixel rendering, and in extreme cases restore legibility
Font-smoothing mimics partial pixels. Compared to black and white rendering, where a pixel is either on or off, gray-scaling tries to represent partial pixels by lighting full pixels in shades of gray between black and white. This allows intermediate weights on stems rendered at in-between positions and hence improves inter-character spacing, but it takes away from the stark contrast between black and white and thus the perceived sharpness of the rendered characters.
Subpixel rendering uses shades of red, green, and blue to shift part of this trade-off into colors.
Partial pixels are a kind of trompe l’œil. Partial pixels mimicked by font-smoothing are a kind of trompe l’œil that end-users don’t seem to appreciate equally. Whether it’s the color artifacts of subpixel rendering or the degree of perceived fuzziness in general, individual tastes and human visual systems respond quite differently, and it comes down to preference.
To me, these differences are important enough that I won’t qualify any particular combination of font smoothing and regularization strategy as “the single best fit for every end-user.”
Addressing diverse end-users. Accordingly, given my background in computing sciences, I strive to engineer outline regularization towards diversity. To do so, I separate the stems from their weights and positions, encode different sets of rules and priorities that apply to these stems, and implement selector switches for choosing individual sets of rules and priorities on-the-fly.
In terms of “conventional hinting” this is like using the same set of “hints” for substantially different outcomes.
In terms of computer code I parameterize the regularization (see Figures 7–10 for a snapshot of these objectives. CAUTION: These figures are best viewed pixel-by-pixel, with your browser’s “zoom” set to 100%).
Fig. 7: Font-smoothing rule set #1. Tie all heights, side-bearings, and stroke weights to full pixel boundaries, allowing font-smoothing to merely smooth the “jaggies.” Notice the sharply defined stems contrasting with the white background, but also notice the pronounced “steps” as stroke weights increase from 1 to 2 and 3 pixels
Fig. 8: Font-smoothing rule set #2. Tie heights and side-bearings to full pixel boundaries, but allow font-smoothing to render strokes with intermediate weights (beyond a minimum weight of 1 pixel). Compared to rule set #1, notice the absence of pronounced “steps” as stroke weights increase from 1 to 2 and 3 pixels while generally maintaining sharply defined characters
Fig. 9: Font-smoothing rule set #3. Allow font-smoothing to render under- and overshoots and stems with intermediate weights at intermediate positions once the stems exceed a minimum weight of 1 pixel. Compared to rule set #1 or #2, notice the improved fidelity of inter-character spacing at larger font sizes and the gradual introduction of under- and overshoots while maintaining legibility down to the smallest font sizes
Fig. 10: For comparison purposes, allow font-smoothing to work completely unimpeded by any form of “hinting.” While this may render characters most faithfully, it is no guarantee for legibility at the smallest text sizes. Compared to rule sets #1 through #3, the smallest sizes look increasingly fuzzy and even the inter-character spacing appears inconsistent
Limitations of low resolution. Computer coding prowess notwithstanding, it is an entirely different question whether or not it makes sense to regularize just about any font, such as a font designed specifically for printing newspapers or high gloss coffee table books, and adapt it for rendering small text on low resolution screens.
As an engineer, I don’t qualify to make this call, nor do I want to convey the impression that every font can be sent down the “resolution funnel” unconditionally. The best I can do is to share my insights into font rendering.
But if there is a need for a print preview with this font, rest assured that “there is a switch for that!”