Caution: Some illustrations on this page are intended to be viewed pixel-by-pixel, without you or your browser adding any “zoom factor.” In the past, pressing “Ctrl 0” to reset your browser to 100% would sort this out but today’s browsers are becoming smarter at identifying how many pixels it takes to cover an inch of your screen and call that 100%. While this works wonders on scalable text rendered on-the-fly, it wreaks havoc on illustrations rendered to be seen pixel-by-pixel, so if you’re unsure you’re seeing what you’re supposed to be seeing, please feel free to download the critical illustrations and inspect them in your favorite pixel viewing app.
“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!
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.
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 2.1a) because the pixels on today’s screens are too large for small text sizes.
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.1b). 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 2.1c). Times New Roman becomes a “Monoline Rockwell,” but compared to the unmodified outlines the outcome remains legible.
|
Fig 2.1a: “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.1b: 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 2.1c: 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 |
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.
“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 2.2), and it can wreak havoc on font smoothing.
|
Fig 2.2: 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 (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 2.3a). It takes “hinting” or regularization to make this legible—notably on a font designed for user interfaces on screen (Fig 2.3b).
|
Fig 2.3a: Font smoothing without “hinting” can reduce unfortunate combinations of font design and text sizes to blobs of gray or lines of vibrating colors Fig 2.3b: 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 |
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 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.”
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 2.4a – 2.4d for a snapshot of these objectives. Caution: These figures are best viewed pixel-by-pixel, with your browser’s “zoom” set to 100%).
|
Fig 2.4a: 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 2.4b: 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 2.4c: 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 2.4d: 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 |
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!”
In internet discussion fora and similar sources of collective wisdom I sometimes read arguments like “Acme’s approach to text rendering (or font ‘hinting’) is to be as faithful to the font design as possible.” This tends to rub me the wrong way because until we all get high resolution displays with something like 1200 dpi pixel density, text rendering continues to be a compromise between being faithful to the outlines and faithful to the black ink. Between these mutually exclusive goals their compromise is just as good as anybody else’s, including mine—no more, no less.
Let me try to explain this: Digital is fantastic—as long as you don’t notice the pixels (Fig 3.1). Traditional hot metal typesetting was an analog process that printed sharply defined characters in solid black ink. There weren’t any pixels that could or could not be noticed, it wasn’t merely more or less faithful to the design, it was the design—or at least a smooth cast replica thereof.
|
Fig 3.1: The pixels required to render a 13 pt lowercase ‘n’ on a 1200 dpi screen. Compared to the size of the letter ‘n’ the pixels are very small which makes it possible to render just about any nuance of its design (Verdana, 217 px). |
Compare this to today’s flat panel screens: pixels are sharply defined little black squares, and they can be as black as solid black ink, but on most screens they are way too large to faithfully represent a character’s design. Merely “turning on” pixels that are interior to the outlines results in a lot of hit or missed pixels much like a basic quality facsimile (Fig 3.2).
|
Fig 3.2: The pixels required to render a lowercase ‘n’ at a range of sizes on a typical screen. Compared to the size of the letter ‘n’ the pixels are large to very large which makes it impossible to render even the most basic design criteria like 2 equal stems or a modest contrast between the horizontals and the verticals (Verdana, 8 to 32 px, covering 6 pt at 96 dpi to 12 pt at 192 dpi) |
To get the coarse pixels to somewhat resemble the original design, a lot of “hinting” is required—careful adjustments to the font outlines to obtain sets of pixels that better represent the designer’s intent—at all font sizes.
Matthew Carter designed the 2 stems of the lowercase Verdana ‘n’ with exactly equal weights, and the contrast between horizontals and verticals is low—the arch of the ‘n’ is ever so slightly lighter than its stems—but few of the sizes in Fig 3.2 faithfully represent either of these design goals without “hinting.”
Now compare this to font smoothing as introduced about two decades ago: at first glance it readily eliminates the pixelation of bi-level rendering, and it may look as if the 2 stems are rendered with equal weights and the arch contrasts with the stems as designed—all without “hinting” (Fig 3.3a).
|
Fig 3.3a: Using font smoothing to render a lowercase ‘n’ at the same range of sizes as in Fig 3.2. Compared to the size of the letter ‘n’ the pixels are as large as before but they are much harder to notice than in Fig 3.2 (and hence the term font smoothing). Basic design criteria like 2 equal stems or a modest contrast between the horizontals and the verticals appear to be portrayed much more faithfully than without font smoothing (Verdana, 8 to 32 px, covering 6 pt at 96 dpi to 12 pt at 192 dpi, Windows Font-Smoothing) |
But on closer inspection a lot of the black ink has given way to a gray “mud”—only a few of the stems appear as crisp as designed while others look blurry, as if they were out-of-focus, or downright “washed out.” So let’s have a closer look at a few sizes to learn why (Fig 3.3b).
|
Fig 3.3b: Using font smoothing to render a lowercase ‘n’ at the sizes 11 to 14 px (enlarged), shown together with the outlines, baseline, x-height, and sidebearings for reference. Depending on where the outline happens to “fall” on the pixel grid, font smoothing can make crisp stem edges look like they are out-of-focus (right edge of left stem of top right ‘n’), seemingly wash out entire stems (right stem of top right ‘n’), and it does not guarantee that 2 equal stems are rendered equally (bottom right ‘n’) |
A more recent font smoothing method with the generic designation subpixel rendering exploits the property of flat panel screens having individually addressable red, green, and blue components (subpixels) for each pixel. It tries to mimic partial pixels by selecting specific shades of red, green, and blue for the individual subpixels (Fig 3.4a).
|
Fig 3.4a: Using subpixel rendering to render a lowercase ‘n’ at the same range of sizes as in Fig 3.2. Compared to the size of the letter ‘n’ the pixels are as large as before but they are much harder to notice than in Fig 3.2. Basic design criteria like 2 equal stems or a modest contrast between the horizontals and the verticals appear to be portrayed much more faithfully than without subpixel rendering (Verdana, 8 to 32 px, covering 6 pt at 96 dpi to 12 pt at 192 dpi, early version of DirectWrite) |
At first glance also subpixel rendering readily eliminates pixelation, much like grayscaling does, but on closer inspection it doesn’t fare much better than grayscaling—if at all (Fig 3.4b).
|
Fig 3.4b: Using subpixel rendering to render a lowercase ‘n’ at the sizes 11 to 14 px (enlarged), shown together with the outlines, baseline, x-height, and sidebearings for reference. Depending on where the outline happens to “fall” on the pixel grid, font smoothing can make crisp stem edges look like they have color fringes (both stems of top left ‘n’), render stems with vibrating colors (right stem of top right ‘n’ and others), and it still does not guarantee that 2 equal stems are rendered equally (bottom right ‘n’) |
Given the problems introduced by font smoothing without “hinting,” the question arises whether to reconsider “hinting”—not the same kind of aggressive pixel popping as in the era of bi-level font rendering, but some form of thoughtful outline “nudging” nonetheless?
Now, having seen the kind of damage incurred by some of yesteryear’s inappropriate “hinting,” merely mentioning that word may be a big red flag. I can feel your pain. But it doesn’t have to remain a big red flag: “hinting” doesn’t have to mercilessly hammer outlines into pixel boundaries nor does it have to mindlessly prioritize advance widths.
For example, in their seminal paper Perceptually Tuned Generation of Grayscale Fonts the authors propose to align the leading edge of straight vertical stems with a pixel boundary while allowing the trailing edge to “incur” a shade of gray to accommodate faithful stem weights (Fig 3.7d).
This is a compromise in that only the first edge encountered in the reading direction—the one the paper proposes to be the more critical one for reading—is sharply defined while allowing the other edge to be blurry. Likewise, this compromise yields a large number of solid black pixels—to maximize density or luminance contrast—while some pixels remain gray.
This compromise illustrates the fundamental dilemma between text rendering that is faithful to the outlines and text rendering that is faithful to the black ink: The stems’ weights are faithful to the outlines, but their positions aren’t. The black pixels are faithful to the black ink, but the gray ones aren’t. Getting things faithful to the design, that is, faithful to both the outlines and the black ink seems like “squaring the circle.”
Moreover, this compromise is merely one attempt at “squaring the circle” out of several others. Depending on the properties of display devices, the priorities of software applications, or the preferences of end-users, other approaches may wish to “nudge” the outlines differently, for a different emphasis on the outlines or the black ink.
Whichever way any approach may “nudge” the positions of stems and other character parts, it is essential to understand that any of these outline manipulations should not be done in isolation. They depend on each other and the final outcome depends on understanding how they depend on each other. So let’s make the connections.
It is a well-known observation that text comprehension is largely based on identifying the top parts of lowercase letters: Text with its top half removed leaves mostly scattered stems for comprehension which makes it substantially impossible to read (Fig 3.5a).
|
Fig 3.5a: A two word phrase with the top part of the (lowercase) letters removed is substantially impossible to read (illustration after Felici, using Tahoma 45 px, corresponding to 9 pt at 360 dpi) |
It takes the top half of the text to “decipher” it, which works at least “sort of” even with the bottom half removed (Fig 3.5b).
|
Fig 3.5b: The same two word phrase as in Fig 3.5a but with its bottom part removed is “decipherable” if awkwardly so (illustration after Felici, using Tahoma 45 px, corresponding to 9 pt at 360 dpi) |
But to make it readable—rather than merely decipherable without eye or brain strain—it would be easier to have both halves (Fig 3.5c).
|
Fig 3.5c: The same two word phrase as in Fig 3.5a but in its entirety is easy to read (Tahoma 45 px, corresponding to 9 pt at 360 dpi) |
Given these findings it stands to reason that the top parts are important enough for the “hinting” or “nudging” to consider aligning the x-height—the tops of the lowercase letters—with a pixel boundary, to make them as sharply defined as possible (Fig 3.6).
|
Fig 3.6: Before (left) and after (right) “nudging” the top bar of the letter ‘z’, aligning the x-height with a pixel boundary. Notice the increased number of black pixels, the sharply defined edges of the top bar, and the consistency between the top and bottom bars (Verdana, 12 px) |
Aligning the x-height with a pixel boundary may not always help as dramatically as with the top bar of the lowercase ‘z’ but given Felici’s convincing example and for consistency we’ll use any help we can get on the lowercase ‘n’ and ‘o’ (Fig 3.7a).
|
Fig 3.7a: Before and after “nudging” (top and bottom) the arch of the letter ‘n’ and the top round stroke of the letter ‘o.’ While the raw number of black pixels doesn’t increase as dramatically as in Fig 3.6, the density of these parts does increase appreciably, and so does the consistency between the top and bottom round strokes of the letter ‘o’ and among the tops of the rest of the alphabet (Verdana, 12 px) |
Recall that for straight vertical stems Hersch & al propose to align the leading edge with a pixel boundary while allowing the trailing edge to “incur” a shade of gray. For round stems they propose to “allocate” the gray on the outside, as opposed to the trailing edge. Doing so renders the letter ‘o’ with suitable symmetry, it generally helps to smooth all rounded shapes, and it maximizes the number of black pixels for luminance contrast.
However, positioning the straight and round stems to follow these “gray rules” requires careful deliberation: It may be tempting to pick each stem individually and “nudge” it to the nearest position compatible with its corresponding “gray rule,” but doing so may position the pair of stems too close together for the closest representation of character proportions (Fig 3.7b).
Recall that aligning the x-height with a pixel boundary made the lowercase ‘z’ a little bit taller hence let’s “nudge” the stems the other way to move them further apart (Fig 3.7c). The proportions of the lowercase ‘o’ seem a lot closer to the design now but the ‘n’ looks as if it might be too wide. It takes an algorithmic approach to determine which ‘n’ has the black body width that comes closer to the design, factoring in both the aligned x-height and the specific “gray rules” for stem positioning—at all sizes.
|
Fig 3.7b: Before and after “nudging” (top and bottom) the straight and round stems of the letters ‘n’ and ‘o’ to implement the “gray rules.” Notice again the increased number of black pixels, the vastly increased consistency between the left and right stems of the letter ‘n,’ and the increased consistency and symmetry between the left and right stems of the letter ‘o.’ Notice also that both letters appear to be too narrow, particularly so the letter ‘o’ (Verdana, 12 px) Fig 3.7c: Before and after “nudging” (top and bottom) the straight and round stems of the letters ‘n’ and ‘o’ to implement the “gray rules.” Notice that in contrast to Fig 3.7b the stems are “nudged” the other way to better represent the true character proportions. Notice also that the letter ‘n’ may look as if it were too wide, but considering the aligned x-height it actually represents the true proportions more closely than the narrower version in Fig 3.7b (Verdana, 12 px) |
Fixing the character proportions within the constraints of the “gray rules” for stem positioning rules does not consider the sidebearings and in turn the inter-character spacing. Adjusting the sidebearings to “follow” the adjusted black body widths eliminates this problem (Fig 3.7d).
|
Fig 3.7d: Before and after adjusting the advance widths (top and bottom) to allow prioritizing both the black body widths for correct character proportions and the sidebearings for correct inter-character spacing. Notice the positions of the sidebearings, represented by green lines, and in particular the position of the right sidebearing lines of the letter ‘o’ (Verdana, 12 px) |
Something along those lines seemed to be the non-debatable rule throughout my professional career, on the premise that changing any of the advance widths will jeopardize wysiwyg in the “Print View Mode.” But, as you can see, I just did it. I changed the advance width of the letter ‘o’ as rendered and both the character proportions and the spacing are just fine (Fig 3.7e, bottom row). It’s all connected—we cannot execute any of these “nudging tweaks” in isolation, and hence what’s the problem with changing the advance widths?
The problem is that changing the advance widths can cause the wysiwyg algorithm to exacerbate the havoc it wreaks on the inter-character spacing to make sure that the characters we see on our low-resolution screens are laid out in the exact same way as the ones we’ll get from our high-resolution printers—but merely leaving the advance widths alone does not guarantee there won’t be any havoc.
That’s because in practice the different resolutions of the screens and printers almost always cause “round-offs” that have to be “absorbed” on screen by literally squeezing or tugging characters to somehow make the same words fit on the same lines. Doing so almost always damages character proportions or spacing—or both. What a kludge!
From that perspective, the purest way to implement wysiwyg is to start out from the pixels rendered for the high-resolution printer and then down-sample these pixels to the low-resolution screen like making a postcard or a thumbnail out of a high-resolution photograph. This may be harder to read because of the blur incurred by down-sampling the pixels, making it look like it is totally “un-hinted.” But remember, wysiwyg‘s promise is to let you see what you’ll get from the printer, not to let you read what you’ve just typed.
Hence the question: how often do we read text on-line or on an eBook reader nowadays and never print it out? Thus why prioritize the advance widths over the character proportions or the inter-character spacing? And if prioritizing the advance widths continues to be imperative to assist some wysiwyg algorithm, remember that fonts are software and that therefore said priority doesn’t have to be “hard-wired” into the font software—that’s why it’s called software, not hardware.
Let’s recap what we did so far: We aligned the x-height with a pixel boundary to satisfy Felici’s convincing argument. Next we followed the “gray rules” as proposed by Hersch & al to position the straight and round stems in specific ways to make them sharply defined while at the same time staying true to their weights. Repositioning these stems can change the black body widths so we picked pairs of stems that most closely represent the true character proportions while remaining compatible with the “gray rules.” Finally we added the sidebearings on the outside of the adjusted black body widths to define (or redefine) the advance widths.
In the examples shown, the adjusted black body width plus the sidebearings of the ‘n’ added up to the advance width as designed and rounded to the nearest pixel boundary, but for the ‘o’ it didn’t (Fig 3.7e, top row), hence we increased the advance width of the ‘o’ to accommodate the black body width that was adjusted as a result of prioritizing the proportions of the ‘o’ (Fig 3.7e, bottom row).
Conversely, to avoid touching the advance widths we would have to subtract the sidebearings from the given advance widths and then leave the remaining pixels to the black body widths, which can compromise the character proportions (Fig 3.7e, middle row).
|
Fig 3.7e: The advance width of the ‘o’ was designed to be a little less than that of the ‘n’ which—after translation to pixels at this type size —amounts to a full pixel. The respective “round-offs” must be absorbed by compromising the inter-character space (top row) or the character proportions (middle row) merely to prioritize the advance widths. Conversely, by prioritizing the character proportions and the inter-character spacing, the respective “round-offs” must be absorbed by the advance widths (bottom row). |
In the preceding examples we have looked at one particular font size and deliberated on individual adjustments to the outlines in order to achieve a set of goals: Apply specific “gray rules” for positioning stems while prioritizing character proportions and sidebearings. To better evaluate alternatives to these priorities let’s scrutinize a piece of text at a range of font sizes, with all the sizes following the exact same set of “gray rules” and priorities.
|
Fig 3.8a: Prioritizing advance widths and character proportions (left) instead of character proportions and sidebearings (right) leads to noticeably irregular inter-character spacing—at just about any size of the above waterfall sample (Verdana, 11 to 20 px)
Fig 3.8b: Prioritizing advance widths and sidebearings (left) instead of character proportions and sidebearings (right) leads to irregular character proportions (‘n’ wider than ‘o’), irregular characters (stems of the ‘m’), or irregular inter-character spacing (‘i’ or ‘l’ between characters with 2 stems) (Verdana, 11 to 20 px)
Fig 3.8c: Attempting to prioritize all three—advance widths, sidebearings, and character proportions—as in DirectWrite (left) instead of character proportions and sidebearings (right) must be done at the expense of specific “gray rules” for stem positioning and hence at the expense of sharply defined stems rendered consistently and with as much solid black ink as possible, which is clearly visible at the smallest sizes (Verdana, 11 to 20 px) |
This is the wrong question. There is no winner, because both methods of Fig 3.8c represent a compromise, with individual sets of priorities, and neither method excels at every aspect of font rendering. A better question would be: which method works better for you? Because the rest can be handled in software.
There is just one more thing: Fonts like Times New Roman, unlike Verdana, were designed with a much more pronounced contrast. The horizontal bars are considerably thinner than the vertical stems, and the serifs may be even thinner.
Rendering these thin bars and serifs as faithfully to the outlines as possible will turn them into a washed out light gray, recalling that fractional pixels are mimicked by selecting shades of gray commensurate with the fractional part of the pixel that’s inside the outlines.
For the horizontal bar connecting the 2 stems of an ‘H’ this can turn the ‘H’ into an almost disjoined pair of ‘I’ making it unnecessarily hard to identify it as an ‘H’ (Fig 3.9a). For serifs this can turn a serifed font like Times New Roman into a sans serif font like Verdana (Fig 3.9b).
In order to make the connection—literally—it is necessary to artificially reinforce the thin crossbars, for instance to a minimum weight of 1 full pixel (Fig 3.9b). For the smallest font sizes this will reduce the contrast of the Times New Roman ‘H’ to an almost mono line sans serif letter ‘H.’ This is simply one of the compromises between making the font nice to look at versus making it easy to read.
By contrast, most serifs do not have to be reinforced to Rockwell-like slabs since unlike the crossbar they are not elements of structural importance. Text without overemphasized serifs may be just as legible, if not easier to read, without the “visual noise” caused by caricatured serifs.
Just remember that today’s fonts are software, not hardware, and hence the degree of serif reinforcement can be a parameter of the software: how “much” serif would you like to make it look like a serifed font but without impeding your reading experience? (Fig 3.9c, 3.9d, and 3.9e).
|
Fig 3.9a: The letter ‘H’ after aligning the cap height with a pixel boundary (left) and after “nudging” the stems to follow the “gray rules” (right). The serifed letter ‘H’ looks rather like a disjoined pair of sans serif letters ‘I’ than a letter ‘H’ which can make it hard to read, especially outside of the context of a familiar word (Times New Roman, 12 px) Fig 3.9b: The letter ‘H’ after aligning one of the crossbar’s edges with a pixel boundary (left) and after reinforcing the crossbar to a minimal weight of 1 full pixel (right). The serifed letter ‘H’ now looks rather like a sans serif letter ‘H’, but while it is much easier to read, it has lost most of the contrast between the horizontal bar and the vertical stems (Times New Roman, 12 px) |
|
Fig 3.9c: The letter ‘H’ after reinforcing the serifs a little bit (left) and a little bit more (right). It starts to look like it is a serifed letter but still without overemphasizing the serifs (Times New Roman, 12 px) Fig 3.9d: The letter ‘H’ after reinforcing the serifs even more (left) and to a minimum of 1 full pixel (right). The serifs now look overwhelming and add visual noise that may make it harder rather than easier to read (Times New Roman, 12 px) |
|
Fig 3.9e: The letter ‘H’ repeating the reinforcements of the crossbar and the serifs of Fig 3.9a to 3.9d (top to bottom) for a range of sizes. The effect of reinforcing the crossbar is most noticeable between the 3rd and the 4th row from the top and towards the smaller sizes on the left of these rows. Likewise, the effect of reinforcing the serifs is most noticeable on the remaining rows and again towards the smaller sizes on the left. Conversely, towards the larger sizes on the right of any of these rows there is little or no readily noticeable difference (Times New Roman, 8 to 32 px, covering 6 pt at 96 dpi to 12 pt at 192 dpi) |
Let’s recap this for the final time: We have looked at font-smoothing and subpixel rendering and what it can and cannot do to improve text rendering. We have looked at thoughtful outline “nudging” of stems and other key character parts and how these outline manipulations are interconnected. And we have looked at reinforcing hairlines and serifs to prevent disintegrating characters but without exaggerating serifs.
The font industry may call these outline manipulations “hinting”—akin to “pushing around pixels” on a case-by-case basis using “delta-hints” as a glorified means of “pixel popping.” The way I implement it I prefer to simply call it software: Formally define the goals that need to be achieved, figure out the algorithms that achieve these goals, and finally translate these algorithms into software. Whichever way you look at it, “hinting” can achieve a whole spectrum of goals, so let’s review these goals in hopes that it may broaden your horizon on “hinting.”
In the days of B&W rendering there were few choices to render curves with a limited number of pixels, which may explain the aggressive strategies used to coax some sense of roundness out of the square pixels (Fig 3.10a, left). If the same strategies are used for font-smoothing, there is little or no benefit (Fig 10a, right).
It requires deliberations about character proportions and rendering stem weights as closely to their design as possible (Fig 3.10b left and right) to make any improvements. But it’s easy to go overboard and sacrifice faithfulness to the black ink for faithfulness to the outlines (Fig 3.10c). Modern subpixel rendering methods cannot help here since they basically just shift the burden of using shades of gray into using shades of color (Fig 3.10d).
|
Fig 3.10a: The letter ‘o’ illustrating the “hinting” strategy used in Windows for B&W (left) and tentatively for font-smoothing (right). In pixelated B&W or bi-level rendering, curves are difficult to represent with a limited number of pixels, but merely turning on font smoothing cannot improve this without a “hinting” strategy that fully exploits the opportunities of font smoothing (Times New Roman, 15 px) Fig 3.10b: The letter ‘o’ illustrating remnants of the “hinting” strategy used in Windows for B&W rendering (left) and fully implementing the “gray rules” (right). Aligning both edges of both stems with a pixel boundary—as done in B&W “hinting”—is not inherently wrong; it merely relinquishes the opportunities to render stroke weights that are more faithful to the design, to render strokes with more black pixels, and to render a hint of contrast between the horizontals and the verticals (Times New Roman, 15 px) Fig 3.10c: The letter ‘o’ illustrating what happens when pushing the “hinting” strategy unilaterally towards faithfulness to the outlines—while disregarding the black ink—by eschewing “hinting” in horizontal direction (straight and round stems; left) and additionally in vertical direction (crossbars, arches; right). The black pixels disappear, the left and right round stems become inconsistent with each other, and finally the letter ‘o’ appears to break apart at the top and bottom (Times New Roman, 15 px) Fig 3.10d: The letter ‘o’ illustrating how subpixel rendering does not fare any better than font smoothing when eschewing “hinting” merely for faithfulness to the outlines. Neither GDI ClearType (left) nor DirectWrite (right) render consistent pairs of round stems, and both let the letter ‘o’ break apart at the top and particularly at the bottom. Coincidentally, Quartz tries to overcome this problem by a combination of emboldening and “fuzzying up”—a kind of blanket stroke reinforcement, and not entirely unlike making bad music louder with the intent to make it better (Times New Roman, 15 px) |
So … did you get the gist of it? On their own, neither font smoothing nor subpixel rendering can overcome the coarse pixels on today’s screens. Font smoothing or subpixel rendering compare to high quality printing about like heavily muffled AM radio compares to a live performance at the symphony hall. It takes “hinting” to put some definition into the gray “mud.”
Don’t be fooled by blurry fonts that claim to be “as faithful to the outlines as possible.” This is being unfaithful to the black ink, and it’s akin to a euphemism for being too lazy to do any “hinting.” Today’s fonts really are software that can give you the whole spectrum of crispness at the twist of a knob—ask for it.