[This is the second post in a two-part series.]
I’ve been following the moves and counter-moves surrounding the implementation of font-linking in web browsers for a long time.
As I said in Part I:
Apple and Microsoft are trying to cut a deal. The deal will include a solution to font-linking that’s acceptable to Microsoft and the font industry at large, and also Apple will license Microsoft’s ClearType fonts in addition to the “Web Safe” fonts like Georgia and Verdana they already license. Apple will include the font-linking solution in the next version of Safari which, since Safari is based on open-source WebKit, also puts it into WebKit. From there, Google will adopt it for their own WebKit-based browser, Chrome. Microsoft will include it in the next version of IE alongside EOT.
Maybe I’m exactly right, maybe I’m partly wrong. But things are happening. The pieces on the chessboard are moving.
Apple Is Re-Assessing Fonts, Font Formats, and Font Rendering
“Interoperability” is the buzzword driving this. Changes are coming to the Mac OS. An article in Ars Technica reports:
First, users will no longer be able to select various grades of anti-aliasing like they have in past versions of Mac OS X. The “medium” level—the default for flat panel displays—is now the only option. Users who prefer the light or strong options may be upset by this change—my only guess is this is related to some kind of optimization.
Secondly, Apple has finally dispensed with the proprietary dfont format.
Lastly, Apple is replacing Monaco with Menlo, a monospaced sans serif based on the rather popular DejaVu Sans Mono. Monaco is still included in TrueType format, but Menlo will be the default for Terminal and Xcode.
Safari Now Supports ClearType On Windows
Over the years, Apple and Microsoft have taken, technically and philosophically, two very different approaches to font-rendering. Along with the changes to anti-aliasing on the Mac, with Safari 4.0 on Windows, users can now get font rendering in line with IE and FireFox:
Opera: The Little Dog That Barked But Wouldn’t Bite, Until Now
Håkon Wium Lie, co-creator of Cascading Style Sheets and current CTO of Opera, has been one of the most vocal advocates of font-linking to installable TTF/OTF files. In 2006 he railed about Microsoft’s Forgotten Monopoly. In 2007 he sounded a clarion call in an AlistApart article CSS @TEN. In September of 2008, he addressed the Association Typographique Internationale (ATypI) conference in St. Petersburg, Russia (Transcript).
And yet, version after version, upgrade after upgrade, Opera failed to support font-linking!
It certainly wasn’t a technical problem: Opera Labs had released a special test build of Opera for Windows named Wingogi (now retired) that demonstrated support for font-linking with the Opera engine. Yet time after time, font-linking never made it into a release. Why?
The reason became apparent at the meeting of the W3C working group charged with evaluating Microsoft’s submission of EOT for consideration as a spec. Lie said:
“The only real difference is a legal one, EOT is under DMCA but TTF is not. E.g., if people write programs to take things out of the browser cache, DMCA might apply to us.”
In other words, Lie was worried about legal exposure. Yet somehow between then and now, Lie has come to the conclusion that Opera can finally implement @font-face linking to installable TTF/OTF files without fear. A green light has gone on and font-linking is featured in Opera 10. Have there been private assurances in return for keeping an open mind about future font-file formats to come? Or some other quid-pro-quo arrangement? It does make you wonder what may have taken place behind the scenes to alter the situation, doesn’t it?
Soon, there will be enough browser support in the market to warrant a lot of experimentation. Font services like TypeKit will emerge. Browser makers will continue to tweak their implementations. Will web designers and developers be satisfied with the results? We’ll see.
Readable Web will be reporting, advising, and analyzing as events unfold.