Added a growing list of chapters on “Parameterized Regularization” illustrating my distinctly different view on what the rest of the font making community may call “hinting.” I’ll try to keep this as non-technical as possible but please bear with me—sometimes we simply have to discuss bare naked pixels (cf Parameterized Regularization)
2011-12-07
Added an illustrated explanation of dropout control when combined with anti-aliasing, including full-pixel and sub-pixel anti-aliasing (cf )
2011-09-14
Spun off ClearType (cf ) and added a comparison of sub-pixel anti-aliasing methods (ClearType, CoolType, FreeType, and Quartz, cf )
Added an analysis of inter-character “spacing” in DirectWrite (cf ) and a comparison of text layout with different advance widths (cf )
Revised the explanation on rendering sub-pixel anti-aliased text (ClearType) in color-on-color (cf ) and its sensitivity to gamma correction (cf )
What is this “Raster Tragedy?”
At a training session on occasion of the OpenType Font Jamboree in 1997, I gave a presentation about rendering outline fonts on low-resolution screens. At the time, text was rendered in “black-and-white” by turning pixels “on” or “off.” I illustrated how naïvely scaling the outlines and turning “on” the pixels inside the scaled outlines resulted in severely malformed characters.
Shortly thereafter, the slides of the presentation were converted to <html> and added to the Microsoft Typography website as The Raster Tragedy at Low Resolution. Over time, a surprising number of documents in cyberspace started to refer to the Raster Tragedy—amongst others, threads on Typophile (cf also Typophile), patents granted by the US Patent Office, and encyclopedia articles on Wikipedia. Eventually, some of these references also started to point out that while its fundamentals may still be valid, the Raster Tragedy does not address any anti-aliasing methods.
Accordingly, I started contributing to discussions in mailing lists and on Typophile. But without “infrastructure” to build upon by reference, there is only so much content you can cram into a single post and keep it self-contained. For instance, in ClearType, in XP and Vista on Typophile I tried to explain the Raster Tragedies of Text Layout—a post which promptly got quoted slightly out-of-context in Wikipedia’s page on ClearType.
Therefore I eventually decided to put it all together in one place, instead of scattering individual answers to the font rendering puzzle, in hopes that this may be of any use to end-users, font makers, and software developers alike. This website is the result of this endeavor. And last but not least, the phrase Raster Tragedy originates in a publication by URW’s Peter Karow—credit where credit is due!
Guide to the Reader
This website comprises enough material to qualify for a serious academic textbook. Rendering text on today’s screens is a surprisingly complex subject, since it touches on a broad range of topics from the sampling theorem over computational geometry to general software engineering—with all of the above guided by artistic decisions. To help you navigate this website and make the best use of your time, following is a quick guide to the casual visitor.
If your time is limited, and if you don’t mind tracking links referring to earlier chapters, consider chapter as the core of this website, flanked by the introduction in chapter and the conclusions in chapter . Chapter defines the frequently misunderstood concept of “hinting” along with its relationships to text rendering and text layout methods, and concludes with considerations to move naïve “hinting” from “pixel popping” to computer programming.
If you are serious about rendering text on today’s screens, consider chapters through as the pre-requisite “infrastructure” to fully understanding chapter . In particular:
Chapter discusses the theoretical foundations behind most if not all of the “Raster Tragedies.” It uses plenty of bi-level (“black-and-white”) examples because it is easier to see the problems in bi-level than in any of the anti-aliasing (“font-smoothing”) methods used in subsequent chapters. If you are uncomfortable with the basic high school level math used in the process, try to follow at least the numerical examples that add or subtract pixels, and be sure to read all the recaps in plain English.
Chapter introduces anti-aliasing (“font-smoothing”) methods, including sub-pixel anti-aliasing (ClearType, CoolType, FreeType, Quartz), explains how they work (to the degree that this can be illustrated without using very advanced math), and compares them with each other and with bi-level (“black-and-white”) rendering. Full-pixel anti-aliasing (aka plain “gray-scaling,” or Windows’ “standard font-smoothing”) in particular should be easy enough to grasp in order to acquire an intuitive understanding for the opportunities that all anti-aliasing methods promise.
Chapter illustrates a range of opportunities that become available when using anti-aliasing methods for rendering text. Anti-aliasing does not increase the physical resolution of today’s screens—it does not increase the number of pixels per (square) inch—but it can defuse many of the problems of bi-level (“black-and-white”) rendering. Just be sure to acquire an intuitive grasp of the Anti-Aliasing “Exclusion Principle” to see what can or cannot be done, no matter how fancy the names for the particular anti-aliasing method. Likewise, be sure to use the respective “mouseovers” to experience the impact of using fractional advance widths and fractional ppem sizes.
Chapter discusses a range of challenges pertaining to the TrueType rasterizer on Windows platforms. It may very well be the most “technical” chapter of them all, but don’t let this turn you off altogether: Similar to Chapter 1, if you are uncomfortable with the basic high school level math or the TrueType code examples used in the process, try to get at least an intuitive understanding from the illustrations and the recap paragraphs in plain English. I would consider both ClearType & “Legacy Fonts” and ClearType & “Legacy Applications” as key to understanding some of what you’re seeing on today’s Windows screens. In particular, be sure to check out the interactive illustration of advance widths (character metrics) towards the end of .
Chapter illustrates the path a glyph takes from the rasterizer’s TrueType processor (the part that executes the TrueType instructions) until (color-) pixels have appeared on screen. Skip the TrueType code (I included it as evidence), but be sure to develop an intuitive understanding of rendering text in color and gamma correction. The buttons below the illustrations are there to experience what under- or overcorrection does, both to the colors and the perceived stem weights. Likewise, be sure to use the respective buttons and “mouseovers” to see the importance of matching the native resolution and sub-pixel structure of LCDs (flat panel screens).
Chapter defines the frequently misunderstood concept of “hinting” along with its relationships to text rendering and text layout methods, and concludes with considerations to move naïve “hinting” from “pixel popping” to computer programming. Once more be sure to use the buttons and “mouseovers” to see what different “hinting” strategies will do at different point sizes, screen resolutions (DPIs), and with different gamma corrections. Also once more, you may of course skip the TrueType code used towards the end of the chapter. I have included it as evidence to demonstrate that a purportedly artistic decision “to correctly place the crossbar” can be made in computer software without the intervention of humans manually applying a plethora of delta instructions: The computer is not [re-]designing Bodoni’s font; it merely processes software to adapt the font as closely as possible to the coarse grid of the screen.
Writing about font rendering is often—if not always—a bit of a dilemma: How technical does it have to be to convince the engineering audience that I’m not just making up all of this stuff, and how technical can it be before I completely lose the type designer audience? This line is not well-defined, and I’m sure I’ve crossed it many times. At the same time bridging that gap between intuitive art and rigorous engineering is what keeps me motivated. It’s not about “either-or” nor “one vs the other”—it’s about both: one and the other. Hope this helps!