Although Matthew Carter is overseeing the project and David Berlow of The Font Bureau is leading development, I’m feeling twitchy about Verdana Pro, a new print family from an old screen face.
Start there: Verdana was born of the screen. In particular, as all reading this know, it was born of the needs of the crude, non-anti-aliased, 72/96 ppi desktop screen of the mid-1990s. At Microsoft’s behest, Matthew Carter created the original cross-platform Verdana with its generous x-height so computer users, whether PC- or Mac-based, would have a sans-serif that was easy to read at small sizes.
Verdana is a font that looks gorgeous at 11px in a non-antialiased environment, and handsome at 9px and 10px in that same setting. Make it any bigger than 11px, and it looks grotesque. Set it via ems or percentages rather than pixels—as most accessibility-conscious designers do—and you ding its perfection. View it in a sub-pixel antialiased environment (i.e. on a modern platform) and, if it is small enough and near enough to an exact pixel size, it still looks nice and reads well … but not nearly as nice or as well as it does in the environment for which it was originally created.
Yes, if you are a genius like Matthew Carter or David Berlow, you can take a screen font, even one of the two definitive screen fonts of the 20th century—the other being Carter’s Georgia, which also looks best at exactly 11px in a non-antialiased environment, though it survives handsomely in modern environments and at inexact, percentage-based sizes—and build a true print family around it. But the idea makes me twitchy.
And that screen guy’s twitch I can’t quite shake makes me start to understand how type designers may be feeling as they watch their gorgeous high-resolution creations, rooted in hundreds of years of craft and technology, take the first small steps toward a new world of web fonts.
Opera loves my web font
And so do my iPhone and your iPad. All it took was a bit o’ the old Richard Fink syntax and a quick drive through the Font Squirrel @Font-Face Kit Generator (featuring Base 64 encoding and SVG generation) to bring the joy and wonder of fast, optimized, semi-bulletproof web fonts to Safari, Firefox, Opera, Chrome, iPhone, and Apple’s latest religious device.
Haven’t checked IE7, IE8, IE9, or iPad yet; photos welcome. (Post on Flickr and link here.)
What I learned:
? Even if manufacturer supplies “web font” versions with web license purchase, it’s better to roll your own web font files as long as this doesn’t violate the license.
Opera hates my web font
So I’ve wanted to use a condensed, bold Franklin typeface for my site’s headlines since, well, forever. So I bought Fontspring’s fine Franklin Gothic FS Demi Condensed and licensed it for @font-face use for a mere $2.99, an incomparable value.
It looks great in Safari, Chrome, and Firefox, but not so nice in the latest version of Opera, where it resembles the inside-out test monkey in Cronenberg’s “The Fly.” (Okay, okay, it looks like a ransom note, but the monkey simile was more picturesque.)
And this, my friends, is why Typekit exists. Because even when you find a great font that’s optimized for screen display and can be licensed for CSS @font-face use, guess what? There is almost always some glitch or bug somewhere. And Typekit almost always seems to find and work around these bugs. It’s the kind of grueling task designers hate dealing with, and Typekit’s team loves solving.
If this were a client site, I’d switch to Typekit, or try licensing a different vendor’s Franklin, or (if neither of those options proved satisfactory) dump web fonts altogether and use Helvetica backed by Arial instead. But as this is zeldman.com, I’d rather nudge my friends at Opera to look into the problem and fix it. This will make browsing zeldman.com in Opera a somewhat weird experience, but hopefully it will help all Opera users in the long run.
Implementation Notes and Details
I haven’t made an SVG version yet, so the web fonts don’t work in iPhone or iPad.
iPhone and iPad see normal weight Helvetica instead of bold Helvetica, because if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font. This is not smart of Firefox. Fixed via technique below.
In order to match the impact of the previous Helvetica/Arial bold, I boosted the font-size from 25px to 32px. (This also helps smooth the font. Web fonts need more help in this regard than system fonts.)
Camino ignores @font-face and supports the first system font in the font stack, Helvetica Neue (correctly styled bold).
GEORGIA and Verdana, Lucida and (to a lesser extent) Arial and Times New Roman have served us well. For fifteen years, these cross-platform default fonts have been faithful stewards of our desire to read, write, design, and publish web pages. Yet we designers have always wanted more. As far back as 1994, we hoped for the day when we could brand our layouts as magazine and poster designers do, by setting our pages in Franklin or Garamond, our headlines in Futura or Rosewood. And since 1998, CSS2 has provided a standard way to embed any typeface, not just the fab five, on a web page.
In August, 2007, CSS co-creator and Opera Software CTO Håkon Wium Lie wrote CSS At Ten, reminding us that CSS provided a mechanism by which actual font files could be linked to and retrieved from the web. Soon after the article was published, “web fonts” discussions started popping up at interactive design festivals and my friend Jeffrey Veen got the idea for a product that would get web fonts happening without running afoul of inconsistent browser support, multiple format hangups, or type designer licensing agreements and piracy concerns.
Speeding up design acceptance
While browser improvements and web standards alone provided multiple partial solutions, Typekit offered a complete solution that just worked. And the people behind Typekit (including Bryan Mason and Jason Santa Maria) did everything right: they reached out to the type design, graphic design, and standards-based web design communities; they worked with vendor after vendor to offer as many fonts as possible; they spoke everywhere, marketing their venture one lecture and even one designer at a time.
Typekit excited the web design community about type and proved that licensing and hosting web type was a viable business, providing options and convenience for designers and their clients, while bringing new revenue to type designers and protecting their intellectual property.
Typekit is the tipping point
Publicly and truly, I support Typekit because it is getting us to the world of web fonts faster. We could wait indefinitely for type vendors to agree to industry-standard licensing terms and font formats. We could wait far longer for IE, Firefox, Safari, Chrome, Opera, Opera Mini, Mobile Safari, and the rest to support the same font formats. (Currently Firefox supports WOFF and TrueType, Safari and Chrome support TrueType, MobileSafari supports SVG, IE supports EOT, and on, and on.)
But with Typekit, we don’t have to bother our pretty little heads worrying about these inconsistencies, and we don’t have to sit on the sidelines, waiting for all font makers and all browser makers to support a single standard format.
Platforms and performance
Typekit works, and that helps web designers and type designers take “web fonts” seriously. Typekit’s success is even helping to make web designers and type designers more aware of platform problems that can make fonts hideous on various platforms. Georgia was designed for the screen. Garamond was not. Moreover, platforms vary the way they hint fonts (Apple throws out hinting altogether, Microsoft over-hints) and the way they render them (from purely pixellated to at least three varieties of sub-pixel anti-aliasing), making a font’s appearance on a given user’s system hard to predict.
If not for Typekit, we might have had to wait years for most or all type designers to license web fonts. Only then would we have discovered that body text set in anything other than Georgia and Verdana pretty much blows on many Windows OS, browser, and monitor combinations.
Thanks to Typekit, we all know about the problem, and type designers are re-hinting their fonts, and in some cases redesigning them for the screen.
For all this I and all of us can be grateful to Typekit.
They also understand that designers will only use “web fonts” if they have access to the fonts they need. Just as a huge selection enabled iTunes to dominate online music, Typekit’s makers know their service must offer pretty much every good typeface out there—and they are working on it.
Renting versus “owning”
All this said in Typekit’s favor, I have mixed feelings about their product because I’d rather buy a web-licensed font than rent it—and Typekit’s success at establishing the viability of a rental model means that individual type foundries will also rent their fonts—and those who succeed at renting their fonts to web designers may not be inclined to sell.
Of course you never really own the fonts you buy—you simply license their use. So the analogy of owning versus renting doesn’t exactly hold true. But a one-time font purchase as a line item in a design budget is easier to explain and sell to a client than an ongoing rental charge.
Web Standards and @font-face
My other qualm has to do with a preference for pure web standards over product-assisted web standards. I don’t know if my preference is ideological or just the way my mind works (or fails to). But, given my druthers, I’d rather see millions of websites using standard @font-face to link to self-hosted web-licensed fonts than see that same number of fonts using a service—even a brilliant service created by friends for whom I wish continued, deserved, great success. It must be a quirk of mind; there’s no other logical explanation for this preference.
For those who share this bias, possess the properly licensed fonts, and don’t mind using FTP and writing a little code, the CSS @Font-Face Generator by Font Squirrel provides an exceptionally easy way to automatically generate the font formats necessary to take all browsers (including mobile) into account—complete with automated Cufón backup and your choice of best-practice @font-face code strings.
Web designer Joshua Lane, currently best know for doing fancy web stuff at Virb.com, has overhauled his personal site in ways that are aesthetically pleasing and visually instructive.
Like all good site redesigns, this one starts with the content. Whereas the recent zeldman.com redesign emphasizes blog posts (because I write a lot and that’s what people come here for), Lane’s redesign appropriately takes exactly the opposite approach:
There is a much smaller focus on blog posts (since I don’t write often), and a much larger focus on the things I do elsewhere (Twitter, Flickr, Last.fm etc). Individually, I don’t contribute a great deal to each of those services. But collectively, I feel like it’s a good amount of content to showcase (as seen on the home page). And something that feels like a really good representation of “me.”
The great Barry Schwartz based his Goudy Bookletter 1911 on Frederic Goudy’s Kennerley Oldstyle, a font Schwartz admires because it “fits together tightly and evenly with almost no kerning.” Lane inserts Schwartz’s open-source gem via simple, standards-compliant CSS @font-face. Because of its size, it avoids the secret shame of web fonts, looking great in Mac and Windows.
But considered type is far from the redesigned site’s only nicety. Among its additional pleasures are elegant visual balance, judicious use of an underlying horizontal grid, and controlled tension between predictability and variation, ornament and minimalism. Restraint of color palette makes photos, portfolio pieces, and other featured elements pop. And smart CSS3 coding allows the designer to play with color variations whenever he wishes: “the entire color scheme can be changed by replacing a single background color thanks to transparent pngs and rgba text and borders.”
In short, what Lane has wrought is the very model of a modern personal site: solid design that supports content, backed by strategic use of web standards.
New Franklin in Town
There’s a new Franklin in town. It’s TeeFranklin, designed by Tomi Haaparanta for T26. Haaparanta specializes in what we used to call grunge fonts, but you’d never know from his Franklin, which is classic and pure. In terms of available weights and styles (not to mention fanatical attention to detail), Haaparanta’s new font can’t compare to Font Bureau’s ITC Franklin, but TeeFranklin is a nice and clean, and comes in 14 weights, which may be enough. Better still, according to reader Ethan Dunham, it is licensed for @font-face embedding.
Nice Web Type For iPhone
m.nicewebtype.com is a light yet essential mobile site for people who design websites, love type, and struggle to keep up with the dizzying world of web fonts. In it, Tim Brown, author of Nice Web Type, creator of Web Font Specimen (what’s that?), and latterly type manager for Typekit, curates the Design Twitterverse to share the latest insights, innovations, quips, and controversies regarding everyone’s favorite new web design fetish.
Don’t leave home without it.
Three Days in Seattle
Three, count ’em, three days of design, code, and content. That’s what we’ve got lined up for you in beautiful Seattle, Washington. Including a special one-day workshop on HTML5 and CSS3, led by Jeremy Keith and Dan Cederholm (pictured above, extolling the virtues of caffeine and CSS).
The complete schedule for An Event Apart Seattle 2010—including A Day Apart with Jeremy Keith and Dan Cederholm—is now available online for your listening and dancing pleasure.
Real Fonts and Rendering: The New Elephant in the Room
My friend, the content strategist Kristina Halvorson, likes to call content “the elephant in the room” of web design. She means it’s the huge problem that no one on the web development team or client side is willing to acknowledge, face squarely, and plan for….
Without discounting the primacy of the content problem, we web design folk have now birthed ourselves a second lumbering mammoth, thanks to our interest in “real fonts on the web“ (the unfortunate name we’ve chosen for the recent practice of serving web-licensed fonts via CSS’s decade-old @font-face declaration—as if Georgia, Verdana, and Times were somehow unreal).…
Put simply, even fonts optimized for web use (which is a whole thing: ask a type designer) will not look good in every browser and OS.