Web fonts — the death of type foundries?

Published • 13 Nov 2008

In the spirit of Halloween Jon Tan covered the ominous topic of @font-face linking in a comprehensive article on his beautiful website. Font-linking continues to occupy heated discussion as a contentious topic between type-savy web developers, type designers, and type foundries with the heart of the debate focusing on licensing and copyright issues.

I’ve kept the implementation example to a minimum because it’s well covered by Jon, other websites, and the W3C. Instead, I wanted to voice my thoughts on the struggle between type foundries and designers. Feel free to skip the technical summary.

Implementation summary

‘Web fonts’ is currently a W3C CSS3 working draft. It allows for the direct linking to font files that are then used by the browser to set text in, broadening the relatively limited palette of ‘web-safe’ typefaces. Many designers have been longing for direct font linking since the earliest days of CSS. This is achieved with the @font-face element:

@font-face {
    font-family: 'Desired-Font';
    src: url('Desired-Font.otf') format('opentype');
    }

After defining the @font-face element, you can directly refer to the linked font with the font-family property:

body {
    font-family: 'Desired-Font', …;
    }

Embedded OpenType

We’re all used to the major browsers not behaving in cohesion and web fonts is another victim of this. Presently @font-face is supported in WebKit (and consequently browsers that use it), Mozilla Firefox 3.1 beta and the development version of Opera. Internet Explorer (IE) — again, not surprisingly — does it’s own thing. Enter Microsoft’s proprietary Embedded OpenType (EOT). EOT was an endeavor by Microsoft to allow for font file linking on the web while safeguarding the typeface from being illegally copied by embedding the font, document to font and font to document. Linked fonts only are linked in one-way, document to font, allowing users to obtain the font with little difficulty. With Microsoft firmly opposed to supporting native OpenType linking as long as vendors object to it, EOT is set to be the only method available in IE for use with @font-face.

Technologically it’s not the greatest solution — see Jon’s frustrations with Microsoft’s ‘WEFT’ converter that produces EOT files from OpenType files (1, 2, 3) and web security analyst Chris Shiftlett’s thoughts on web fonts. There are a range of other and related issues that were discussed at a W3C meeting on EOT and font embedding. These problems will impact its chances of adoption as a standard. In 2007 Microsoft tried to push EOT to be part of CSS but this move was rejected, and they have since resubmitted it as a standalone submission. If EOT is accepted Microsoft would have to ‘open’ the technology to allow for the cross-platform creation of EOT files. This will greatly hinder the adoption of EOT by the W3C, and for good reasons. For EOT to truly catch on it would effectively have to be open sourced… …leaving that thought to die lonely at the bottom of a well. Perhaps I‘m being somewhat too cynical; it would be a pleasant surprise if Microsoft were to open EOT.

Existing alternatives

Besides image replacement, there are a few other options that bring additional typefaces to the web which aim to retain text accessibility and degrade gracefully when viewed in unsupported user agents. One is sIFR and the second and more recent, typeface.js. However neither is suitable for setting anything more than headings or a few lines. sIFR uses Flash, which isn't a standard and quickly begins to affect page load times as well as resources; typeface.js meanwhile doesn’t allow the selection of the rendered text. These alternatives would not compete with font linking if were to become a supported standard.

Finding opportunity in change

The technology implementation aside, direct font linking has raised licensing and copyright issues. Most type foundries that sell fonts, or rather sell licenses for fonts, naturally prohibit direct linking on the web. Foundries are afraid users will make copies of the linked fonts, putting an end to the foundry as the distributor. In the case of font linking, it would be menial for a user to extract the font of a web page: simply open the CSS source, locate the @font-face definition and save the font file referenced in the src: property.

Type foundries are the product of a change in technology, specifically the invention of the movable type and the printing press. Foundries have for the past four and a half centuries thrived through further advances, such as lithography in the 19th century, the invention of the typewriter and again adapted with the rising popularity of the personal computer in the 1980s. Gradually the entry barrier to printing was lowered. To print whatever you desired in 15th–19th centuries you either had to own a printing press or have some awesome friends; today anyone with a $1,000 computer and a $100 printer can print whatever they like and if you have access to public computing and printing services (your public library for instance) you could even do it for free.

Type foundries (like other industries) were forced to adjust their business models with the invention of each new printing technology. Industries that don’t adapt generally whither, giving way to those that do. It is silly to assume you can endlessly make money selling licenses to the same thing while everything about you changes. Something of the sort is what is happening here.

In the fear that their revenue streams will be undercut type foundries are reacting adversely to the topic of font linking and even font embedding. Instead of seeking new opportunities in the advent of these technologies, type foundries are reluctant to support web fonts. Illegal copying and sharing of typefaces is of course a bad thing for foundries and I empathise with them on that level, but I fail to empathise with them in regards to font embedding. Foundries need to realise that as typography becomes liberalised through the advancement of technology (namely the personal computer and the Internet), they must adapt and change with the rest of us. Respected typographer and web developer Richard Rutter wrote in July on the subject of font embedding with his article, The future of font embedding:

…[I]t’s high time that font foundries and type designers stopped waving their hands in the air proclaiming the death of their industry, insisting that everyone will be pirating their fonts and installing them for free. Instead they should see this as an opportunity to be grabbed with both hands.

Hosting & licensing service

Font embedding if implemented correctly as an open standard should be seen a new opportunity for foundries to sell fonts to a whole new market. One suggestion also advocated by Richard is for foundries to host embedded font files and sell them for use on websites. This would be in addition to the conventional model of selling licenses to weights and styles of a typeface individually or as a complete family based on the number of processors you intend to use them on (thankfully most foundries have realised the error in this and are now selling licenses per computer or per site, etc.).

This web licensing and hosting service would be one dandy (and profitable) solution. I do not have a clear-cut answer to this debate but ultimately in my experience the force of change is greater than any single proprietary interest and consequently always wins. Sometimes it takes a while and depending how involved parties react, things can get ugly, which sucks for everyone. What excites me are those who find new opportunities that flourish with the new developments. I hope foundries see this as one of those opportunities and not the extinction of their industry; I look forward to ditching hacks in favour of standardised and open font embedding — or even linking — because there are bigger fish to fry.

For anyone interested reading more, check out the W3C report on for and against standardising font embedding.

For referencing: permalink to this article.