The Raster Tragedy at Low-Resolution Revisited:
Opportunities and Challenges beyond “Delta-Hinting”

Beat Stamm, PhD
Physicist, Computer Scientist, and Aspiring Artist

Are you a Repeat Visitor?
→ Check out What’s New?
→ Select a Chapter on your right

Are you a First Time Visitor?
Consider starting here:
What is this “Raster Tragedy?”
Guide to the Reader

Chapters:
→ 0 Introduction
→ 1 Fundamentals
→ 2 Opportunities: Rendering Methods
→ 3 Opportunities: Constraints
→ 4 Challenges: TrueType Rasterizer
→ 5 Challenges: Putting it all together
→ 6 Discussions
→ 7 Conclusion

What Others are Saying:

John Hudson, Tiro Typeworks:
All of Chapter 6 should be required reading, and then required re-reading.

Thomas Phinney, WebINK:
If you want to understand font rendering on screen, read this. [...] Highly recommended.

Erik Spiekermann (via Twitter), SpiekerBlog:
Required reading for anybody who has to make words on screens.

Jonathan Hœfler (via Twitter), Hœfler & Frère-Jones:
Those wondering “why webfonts take so long” are hereby directed to Beat Stamm’s excellent resource.

What’s New?

2011-12-07

2011-09-14

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:

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!