KLEPAS.ORG

In the spirit of Hal­loween Jon Tan covered the ominous topic of @font-face linking in a com­pre­hen­sive article on his beau­ti­ful website.

I’ve kept the imple­men­ta­tion example to a minimum because it’s well covered by Jon, other web­sites, and the W3C. Instead, I wanted to voice my thoughts on the strug­gle between type foundries and design­ers. Feel free to skip the tech­ni­cal summary.

Implementation summary

‘Web fonts’ is cur­rently 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, broad­en­ing the rel­a­tively limited palette of ‘web-safe’ type­faces. Many design­ers have been longing for direct font linking since the ear­li­est days of CSS. This is achieved with the @font-face element (fig. 1).

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

Fig. 1. After defin­ing the @font-face element, you can directly refer to the linked font with the font-family prop­erty:

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


Embedded OpenType

We’re all used to the major browsers not behav­ing in cohe­sion and web fonts is another victim of this. Presently @font-face is sup­ported in WebKit (and con­se­quently browsers that use it), Mozilla Firefox 3.1 beta and the devel­op­ment version of Opera. Inter­net Explorer (IE)—again, not surprisingly—does it’s own thing. Enter Microsoft’s pro­pri­etary Embed­ded Open­Type (EOT). EOT was an endeavor by Microsoft to allow for font file linking on the web while safe­guard­ing the type­face from being ille­gally copied by embed­ding the font, doc­u­ment to font and font to doc­u­ment. Linked fonts only are linked in one-​way, doc­u­ment to font, allow­ing users to obtain the font with little dif­fi­culty. With Microsoft firmly opposed to sup­port­ing native Open­Type linking as long as vendors object to it, EOT is set to be the only method avail­able in IE for use with @font-face.

Tech­no­log­i­cally it’s not the great­est solution—see Jon’s frus­tra­tions with Microsoft’s ‘WEFT’ con­verter that pro­duces EOT files from Open­Type files (1, 2, 3) and web secu­rity analyst Chris Shiftlett’s thoughts on web fonts. There are a range of other and related issues that were dis­cussed at a W3C meeting on EOT and font embed­ding. These prob­lems will impact its chances of adop­tion as a stan­dard. In 2007 Microsoft tried to push EOT to be part of CSS but this move was rejected, and they have since resub­mit­ted it as a stand­alone sub­mis­sion. If EOT is accepted Microsoft would have to ‘open’ the tech­nol­ogy to allow for the cross-​platform cre­ation of EOT files. This will greatly hinder the adop­tion of EOT by the W3C, and for good reasons. For EOT to truly catch on it would effec­tively have to be open sourced… …leaving that thought to die lonely at the bottom of a well. Perhaps I’m being some­what too cynical; it would be a pleas­ant sur­prise if Microsoft were to open EOT.

Existing alternatives

Besides image replace­ment, there are a few other options that bring addi­tional type­faces to the web which aim to retain text acces­si­bil­ity and degrade grace­fully when viewed in unsup­ported user agents. One is sIFR and the second and more recent, typeface.js. However neither is suit­able for setting any­thing more than head­ings or a few lines; sIFR uses Flash, which isn’t a stan­dard and quickly begins to affect page load times as well as resources; typeface.js mean­while doesn’t allow the selec­tion of the ren­dered text. These alter­na­tives don’t compete with font linking if were to become a sup­ported stan­dard.

Finding opportunity in change

The tech­nol­ogy imple­men­ta­tion aside, direct font linking has raised licens­ing and copy­right issues. Most type foundries that sell fonts, or rather sell licenses for fonts, nat­u­rally pro­hibit direct linking on the web. Foundries are afraid users will make copies of the linked fonts, putting an end to the foundry as the dis­trib­u­tor. In the case of font linking, it would be simple for a user to extract the font of a web page: open the CSS, locate the @font-face def­i­n­i­tion and save the font file ref­er­enced in the src: prop­erty.

Type foundries are the product of a change in tech­nol­ogy, specif­i­cally the inven­tion of the movable type and the print­ing press. Foundries have for the past four and a half cen­turies thrived through further advances, such as lith­o­g­ra­phy in the 19^th century, the inven­tion of the type­writer and again adapted with the rising pop­u­lar­ity of the per­sonal com­puter in the 1980s. Grad­u­ally the entry barrier to print­ing was lowered. To print what­ever you desired in 15^th–19^th cen­turies you either had to own a print­ing press or have some awesome friends; today anyone with a $1,000 com­puter and a $100 printer can print what­ever they like and if you have access to public print­ing ser­vices (your public library for instance) you could even do it for free.

Type foundries (like other indus­tries) were forced to adjust their busi­ness models with the inven­tion of each new print­ing tech­nol­ogy. Indus­tries that don’t adapt gen­er­ally whither, giving way to those that do. It’s silly to assume you can end­lessly make money selling licenses to the same thing while every­thing about you changes. This is exactly what is hap­pen­ing here.

In the fear that their revenue streams will be under­cut type foundries are react­ing adversely to the topic of font linking and even font embed­ding. Instead of seeking new oppor­tu­ni­ties in the advent of these tech­nolo­gies, type foundries are reluc­tant to support web fonts. Illegal copying and sharing of type­faces 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 embed­ding. Foundries need to realise that as typog­ra­phy becomes lib­er­alised through the advance­ment of tech­nol­ogy (namely the per­sonal com­puter and the Inter­net), they must adapt and change with the rest of us. Respected typog­ra­pher and web devel­oper Richard Rutter wrote in July on the subject of font embed­ding with his article, The future of font embed­ding:

“…[I]t’s high time that font foundries and type design­ers stopped waving their hands in the air pro­claim­ing the death of their indus­try, insist­ing that every­one will be pirat­ing their fonts and installing them for free. Instead they should see this as an oppor­tu­nity to be grabbed with both hands.”

Hosting & licensing service

Font embed­ding if imple­mented cor­rectly as an open stan­dard should be seen a new oppor­tu­nity for foundries to sell fonts to a whole new market. One sug­ges­tion also advo­cated by Richard is for foundries to host embed­ded font files and sell them for use on web­sites. This would be in addi­tion to the con­ven­tional model of selling licenses to weights and styles of a type­face indi­vid­u­ally or as a com­plete family based on the number of proces­sors you intend to use them on (thank­fully most foundries have realised the mistake in this and are now selling licenses per com­puter).

This web licens­ing and hosting service would be one dandy (and prof­itable) solu­tion. I don’t have a clear-​cut answer to this debate but ulti­mately in my expe­ri­ence the force of change is greater than any single pro­pri­etary inter­est and con­se­quently always wins. Some­times it takes a while and depend­ing how involved parties react, things can get ugly which sucks for every­one. What excites me are those who find new oppor­tu­ni­ties that flour­ish with the new devel­op­ments. I hope foundries see this as one of those oppor­tu­ni­ties and not the extinc­tion of their industry—I look forward to ditch­ing hacks in favour of stan­dard­ised and open font embed­ding, because there are bigger fish to fry.

For anyone inter­ested reading more, check out the W3C report on for and against stan­dar­d­is­ing font embed­ding.