At @media London this year, Opera’s CTO Håkon Wium Lie intimated that the forthcoming release of Opera will support downloadable fonts, or ‘web fonts’ in the W3C’s parlance. He reinforced this in an article published on CNET.
Web fonts were introduced in CSS2 in 1998. They then disappeared from CSS 2.1 and reappeared in the CSS3 Web Fonts module, where they have languished as a last call working draft since 2002. The CSS for web fonts is simple: specify a URL for the font to be downloaded using the @font-face construct:
@font-face {
font-family: "Robson Celtic";
src: url("http://site/fonts/rob-celt")
}And add the font to your font-family in the normal way:
h1 {
font-family: "Robson Celtic", serif
}The big question though, is what file should be downloaded? Opera is not the first browser to support web fonts. Internet Explorers 4–6 did so, as did Netscape 4. However IE and Netscape only supported proprietary formats, for example IE required authors to use its free WEFT software to create an embedded OpenType file.
The plan appears to be for Opera to support standard TrueType files of the type already installed on our machines (one hopes that implies OpenType files as well). I can feel the type foundries quaking in their boots.
CSS 3 specifies that downloaded fonts should not be made available to other software – in other words they are kept in a browser cache and not installed on the user’s system. We can probably assume Opera will respect this, but as things stand it still leaves the door open for far easier font piracy; after-all the CSS files say “Hey look here’s the URL of a font file you could steal”. That said, I really hope Opera pull it off and other browsers follow suit.
If Opera does go ahead and implement TrueType downloadable fonts, it will serve to highlight how font publishers have been burying their heads in the sand over the past decade. What they should have been working on is a web service for enabling downloadable fonts. Why not have the CSS link to a font file on the publisher’s server, which send the font file only to a registered domain name. To help scupper the downloading problem, the font file itself could be encoded so as only to work in a browser on a certain domain name. This does sound like a form of DRM, but if you think of it from the point of view of the publishers renting out the font instead of selling it, where’s the harm? It would be the same principle as registering to use Google Maps.
So instead of working with browser manufacturers on creating a standard for a web service which could protect and potentially increase their incomes, the font publishers appear to have shot themselves in the foot through their own inaction, and now face the possibility of even more piracy.
Update. I’ve tried to clarify my points in the comments, particularly regarding what could have happened with fonts as a web service.
Jon Hicks wrote:
To get around the piracy issue, I imagined a system similiar to Google Maps. You get a unique key from a type foundry that only works on certain domains, and hides the actual location of the font file.
I think the foundry that gets on to this first will be a winner.
Carl Camera wrote:
And to further the speculation – browsers can currently display only installed fonts. To display fonts without installation requires on-the-fly image generation. My CMS does this today for headings – but it is impractical for entire pages of text. Fonts would have to be installed on the operating system to be of any practical use. Having a browser seamlessly install a font onto a computer (not to mention automatically uninstalling them) would be quite an achievement.
Reinier Meenhorst wrote:
Interesting post, I hope Opera gets the webtype wheels in motion – we could do with better font options on the web.
As for the font publishers, they seem to look for the music industry for strategic inspiration. I hope by now they will see that this isn’t very sensible.
Alan Trick wrote:
It would be quite a stretch to call it font piracy, since you’re straight out giving people the fonts.
Also, there’s not really any good way to get around this. Keeping the files on the publishers server is useless, because the users are still ending up with them. It’s quite different from Google maps which only needs to give you a small part of the map at a time. The only way to do it reliably is to use some sort of DRM, which, quite frankly, won’t work.
First, DRM doesn’t work, there are some fundamental flaws with it and the music/movie industries are finally realizing this after the nth time their pet DRM format has been hacked. If they had listened to any sane engineer about 5 years ago they could have saved themselves a bunch of cash.
Second, DRM causes red tape (like registering fonts and what not). This might work for large companies who can afford the paperwork, but everyone else will just use the many free fonts out there.
Third, writing a DRM system isn’t exactly trivial. Each OS has it’s own unique font rendering system that has it’s own quirks and such, but writing your own one would be even worse. Doing this could be a recipe for disaster especially if you want to support more than one operating system.
Rich wrote:
Not true – you would be no more giving people the font than web sites give people the images within them.
If the CSS spec is followed then the browser downloads the font into its cache and uses it locally. In the same way that a browser downloads an copyrighted image for display within a web page. The important thing is that the font ‘is not made available to other software’, in other words it is not installed into the OS.
Again only true in so far as users end up with the images in specified in web pages.
The point I failed to make clear here is that TrueType files can contain an amount of meta data, including a switch which enables them to be embedded or not. My proposal is that this switch is extended to cover use within a browser on a domain-basis, so even if the TrueType file is downloaded it would not be able to be installed on the OS or uploaded to a different website from the one it was registered to.
This is a form of DRM, but the difference is the font would be designed to work only from the publisher’s server and not to be downloaded in the first place. In principle it’s the difference between streaming and downloading.
The real point is this could have happened but didn’t.
Barry Bloye wrote:
Jon Hicks said: “I think the foundry that gets on to this first will be a winner.”
Reinier Meenhorst said: “As for the font publishers, they seem to look for the music industry for strategic inspiration. I hope by now they will see that this isn’t very sensible.”
Absolutely. Lets hope the foundries see this as an opportunity rather than a threat. From the reports I’ve seen, DRM-free music hasn’t exactly hurt EMI.
Ned Baldessin wrote:
Trying to protect the fonts by a technical scheme will just not work: it’s DRM and is inherently flawed. You can change the format of the font, you can restrict on the HTTP referer, you can issue API keys, etc. In the end it’s pointless: you’re sending the cyphertext and the key to the attacker. So the client will always be able to decode it, and save it in an appropriate format if needed.
Just like with music, the thing to do is to provide more value than the pirated copies.
The font publishers could have CDNs (content delivery networks, like Akamai and such), with very long cache expiration times, so that the browsers would only download a font once for one site, and all other sites would reference the same URL for that font, so it would be kept in cache. So your hosted font is faster to deliver than the pirated version.
This isn’t a big deal if you only need one display font for titles (~50k download), but what about when you start using 4 or 5 font families?
The font publishers could also provide an anti-piracy service: a spider that downloads the font files, analyses the shapes of and matches them to existing fonts (like whatthefont). So offenders would be easily spotted. The idea is not to go after the people who pirate the fonts (the fonts are already being distributed without DRM today, just like music is being sold on CDs), but to prosecute the companies behind the websites that link to pirated copies of fonts. That’s good old police work, nothing new.
Rich wrote:
Agreed. People will continue distributing fonts in actually the same way they do now. However if web fonts are unprotected (ie. a plain old TrueType file sitting on a server, pointed at by a CSS file) that would make the website owner a party to distribution whether they intended to be or not.
The was exactly what I was driving at.
What if you stick 25 great big photos on your page? Same difference – you either respect your users’ bandwidth or you don’t. And specifying more than 2 fonts on any page is paving the way to typographic hell.
Rob wrote:
WEFT already had this capability built-in – it wrapped up the font file, encoded it, and was only usable by the domains which the site author allowed.
This put the power and responsibility in the site author’s hands, rather than the font creator’s.
DRM ain’t new, just the name is.
Rich wrote:
Yes it did, and the embedded OpenType (EOT) file WEFT created could not be installed onto the operating system. But WEFT suffered from other problems.
In order to create the EOT, you had to tell WEFT which characters you wanted to have included. Not particularly useful for the multi-lingual content management systems of today, although I suppose you could create a document with all possible characters in and get WEFT to process that. But even then it only worked on IE/Win and IE7 no does not support it AFAIK.
Opera saying it will support ordinary TrueType files cuts out that whole conversion step required by WEFT.
Ned Baldessin wrote:
I think we all agree: this is not a technical problem, it’s a business problem.
Even if you wrap your font in DRM, be it with WEFT or something else, people will always be able to re-recreate the TTF file if they want to. Someone will write a program to do it.
What I’d want is to be able to go to www.fonts.com,, and licence Univers Bold Extended for www.mydomain.com.. So the licence would be tied to the domain name. Not to traffic, not to a timeframe, nor anything else.
I’m sure the publishers and font makers would make tons of money.
Rich wrote:
Actually, why bother? I’d just distribute the non-DRM’d files that are currently in existence.
Bingo. It may be in the pipeline.
Chris Hester wrote:
Exciting stuff. This could be the one killer feature that Opera could use to attract more users. And hopefully force other browser makers to follow suit.
I do find it ironic however that Opera are doing this when the browser has problems rendering existing fonts properly, such as Helvetica, on certain computer setups. (There’s a horrid bug where some fonts are replaced by very blocky system fonts instead, making web pages look horrendous). They need to fix that bug first.
Scott Norman wrote:
Bitstream, bitstream.com, has been working on this type of technology for a long time, the first version out worked to degree but had to convert font, etc and there were browser issues. Looks like Bistream still working on it, its there TrueDoc, http://www.bitstream.com/font_rendering/products/truedoc/.. It will be interesting to see what the W3 specs will finally do, it would be nice to have more types of fonts to use but then I could see where people start using wierd fonts, etc. and then make the pages unlegible to read.