I wrote about problems downloading web fonts for desktop use when Google’s Web Fonts debuted, but years later it’s still an issue. There’s no way to anticipate the twists and turns a creative project will take. Designers should be free to play and experiment with typefaces without worrying about running out of time or exceeding a monthly usage cap. Convoluted, fragile workflows only create anxeity, they don’t foster creativity.

Monotype’s SkyFonts service is a nice idea, I guess, but their usage terms seem impractical and unrealistic. The few designers I know who’ve tried it found it restrictive and expensive.

The thing is, with a little knowledge of how web fonts work, using those typefaces in desktop apps is quite easy.

Web fonts are normally provided in three file formats, two of which, TrueType *.TTF and Web Open Font Format *.WOFF, are easily converted back to standard TrueType or OpenType fonts. Because of browser variation and font-face implementations, all three font containers are usually linked from a site’s stylesheets.

To use any web font for comping in desktop apps, just convert the ttf or woff file to otf, then use it like you would any normal font. There are a number of tools for converting fonts, but the following web sites work well enough that I didn’t bother downloading an app.

• Online Font Converter
• Free Online Font Converter
• FontConverter.org
• Font Squirrel’s Webfont Generator

Standard-level Fonts.com accounts allow for self-hosted webfont projects. This means the font files can be downloaded and hosted on the web server alongside other assets like images or stylesheets. Having those files makes converting fonts for comping easy, but it’s just as simple to download the files with a web browser. Any file on the web can be copied, in fact every file viewed on the web already is a copy.

Yes, you can steal fonts using this. Don’t. “Good Artists Copy; Great Artists Steal” wasn’t about shoplifting.

Notes

• Web TrueType fonts often won’t show in menus because their name-tables have been munged to discourage copying/theft. Converting fonts to a different container format makes them work correctly.
• Some woff files didn’t work, in those rare cases the corresponding ttf worked fine–you might need to dig into the stylesheets to find the url.
• Converted web fonts usually have messy names in menus.
• Disable or remove any local copies of fonts when the mockup phase ends. Locally installed fonts can conflict with web versions and lead to maddening discrepencies in testing.

John Gruber of Daring Fireball (thanks for the link!) knows a lot about font-rendering, however in a recent post discussing screen-rotation and sub-pixel text rendering he let this slip:

“I tested it on my Cinema Display with the screen rotated 90°, and, to my eyes, sub-pixel anti-aliasing still looked good.”

That is just preposterous. Aside from his observation being completely wrong, he also revealed a bug in OS X: The current system doesn’t recognize rotated pixel orientations, sub-pixel rendering on rotated screens should probably be disabled automatically. (rdar://problem/5627732)

Here are two screenshots of my browser’s address bar as displayed on my Cinema Display, which clearly shows the difference. The top image is Leopard’s default sub-pixel rendering. The second image is the same bar photographed with my display rotated 90°, the photo was then rotated back in Photoshop for better comparison.

The text was apparently calculated against the presumed horizontal LCD primary orientation. But because the pixels were rotated, several of the letterform stems (verticals) are drawing as full-pixel-width colored lines. The first “h” is especially glaring, its stem and stroke are drawn as a pair of dark red and light blue lines.

Sub-pixel rendering takes advantage of a known horizontal alignment of the three color primaries that make up each physical pixel. The algorithm seems to render text at 3x the horizontal resolution, ignoring the color information and treating each third-pixel as a valid light source to use for drawing letterforms. That 3x width is then striped with red, green and blue to match screen’s component primary ordering. (That was an educated guess)

As Steve Weller stated in the post John linked, the human eye has “pathetic color-resolution”. This fact is exploited all over the place in video, with many formats sampling color only once for every four luminance pixels.

Several things are at play here:

1. Human vision is the bifocal product of horizontally arranged eyes.
2. Most written human language uses letterforms which are vertically oriented and horizontally distinguished. Especially Latin-derived languages.
3. Most human languages read horizontally.
4. Human vision tends to be less color sensitive for motion, or when scanning information (like reading)

It all just kind of worked out perfectly. Digital color reproduction combined our horizontal predisposition with our soft and slow perception of color, and then arranged color primaries horizontally. Text also reads horizontally, and since the viewer is rapidly moving their eyes, we perceive shape and contrast before color. Additionally, Latinate languages evolved letterforms which utilize horizontal variations against a largely regular vertical syncopation. Presto: sub-pixel rendering just seems fantastically obvious.

Regarding John’s closing supposition,

“I’m not sure the iPhones rotating display is reason enough to rule out sub-pixel rendering.”

Based on everything leading up to sub-pixel rendering in the first place, most of the benefits would be lost if the underlying pixel grid was vertically oriented. The sensitivity of computer text falls across the horizontal axis. Adding resolution to the vertical axis isn’t worth the effort.

Sub-pixel rendering is ultimately a transitional technology anyway, a half-step that improves the now while waiting for a better and inevitable future to arrive. Once we start seeing iPhone level pixel-densities all over the place, sub-pixel rendering will began its transition to technology footnote.

Digital displays will someday reach a point where every physical pixel is capable of producing every color of visible light. (And someone will doubtlessly push into near infrared and ultra-violet, claiming increased realism and fidelity). Future displays will also be operating at a density where anti-aliasing may not be necessary at all.

I still think Apple’s decision to use standard anti-aliasing for the Leopard menu bar was a mistake. Unless they’ve got some spiffy high-pixel-density cinema displays ready for MacWorld and enable system-wide resolution independence in 10.5.x, switching to standard anti-aliased text rendering in the menu bar was a change that should have been postponed. The necessary hardware pool just isn’t here yet and the result is an interface that looks markedly worse than it did under previous releases.