define('DISALLOW_FILE_EDIT', true); Web Fonts – unFocus Projects – Kevin Newman and Ken Newman

The Third Option for HTML Font Embedding

In the debate over whether web browser makers should implement .eot font support for Firefox in addition to their support for .ttf files (and .otf), their is an alternative that rarely gets any mention – SVG Glyphs in an html context. This is already supported by Opera 10, Safari 4, and Google Chrome (all prerelease at the time of this post). Using SVG Glyphs this way addresses a number of concerns, which are not often mentioned, or simply not well understood.

This gets sticky, but to understand the need for SVG glyphs you need to understand the debate around DRM. DRM doesn’t work. It’s such a failure, that Apple and others have completely abandoned it in their music formats, and game companies are starting to do the same. The reality is that if the crackers and pirates can get their hands on the material (like an encrypted music file), they are going to strip out the protection. So let’s write off DRM.

That’s not to say we should write off all forms of protection. Since we can’t stop the crackers, let’s concentrate on an area we can do something about, casual piracy. Consider a regular end user, who might view the source of a website, or checks their FireBug Net tab, and grab the font file to either install or use on their own system or website illegally. This is where SVG and EOT can play a role. EOT addresses both of these scenarios out of the box – it can be tied to a particular domain, so it cannot be easily installed on another website or blog, and it cannot be easily installed on an end user’s system folder, since it’s not a regular system font. By default, SVG addresses only one of these two problems – they can’t be installed on the user’s system, but they can be easily copied to another site. However, the EOT domain protection can be mimicked through the use of other web technologies. For example, you could serialize the SVG into a dataURL, and then further serialize that into some javascript (and even obfuscate and encrypt it if you wanted to), where you can do all the domain checks you want. This kind of protection is the ideal solution. It provides the maximum protection that DRM has ever been able to practically offer other – it makes it difficult for honest users to pirate fonts.

It is true that with enough googling, downloads and virus scans, the tools are available to extract something like an installable font from PDFs, SWFs, and even SVG files. For an end user to do that, they need a specific intent to steal the material, as well as a the technical capability to actually pull it off. Here we are back into pirate land, and those guys are more likely to hop on usenet, or bittorrent sites anyway – or their local file server at work, rather than attempt to extract some half version of a font from a PDF, EOT, SWF or SVG font (which tend to be subsetted). Dealing with them is a job for lawyers and the law, and it not a technical challenge. Fighting them on the wrong front will cost more than it nets, in terms of lost sales from not participating (and not making sales), or from the support headaches of dealing with ill-conceived DRM technology.

Having a font format that keeps the honest honest, is not too much for type designers to ask for. They spend a lot of time creating type faces, and frankly, they deserve some kind of protection from casual piracy – protection that is at least on par with the kinds of protection other forms of media are already receiving on the internet – and that even fonts are receiving in other formats, such as PDF and Flash SWF files.

Web browser makers, should implement EOT font support, the format supported by the 10,000 pound gorilla – Microsoft‘s Internet Explorer – which is huge, but they probably will not due mostly to a lack of interest from someone willing to do that work – and maybe other concerns. Since that is the case, SVG glyph fonts are great second choice. They provide all the protection that can be reasonably expected from an online media format, and starting over with a new font format is undesirable, if it means we have to wait for 10 more years to get any progress. The upshot is, it’s already in most of the current alternative browsers! Only Mozilla‘s Firefox has yet to implement SVG glyph support – they do seem ready to do it. The future of HTML font embedding is looking bright!

Update: I saw this earlier, but didn’t have the link handy. In bugzilla bug #119490 comment #15, John Daggett mentions that they plan to add this feature for Gecko 1.9.2. This is great news! It does mean more waiting though, as Gecho 1.9.2 is slotted to run whatever version of Firefox comes after the soon to be released 3.5 (3.6 at the moment).

No Embedded Web Fonts?

I occasionally come across an argument against the implementation of embedded web fonts in web browsers and I wanted to comment on it.

The argument is that embedding fonts in web pages should not be allowed, because either people don’t have the rights to use fonts that way, or because it’s too easy for users to steal the fonts, or some combination of the two. It’s debilitating for those who hold that position, and they may be missing out on a lot of potential opportunity. Craig Kroeger sells a set of fonts specifically for use in Adobe Flash, and even licensed them for distribution with Adobe Flash CS3. And that’s just for Flash designers. Imagine a market the size of the whole internet.

Without proper web font embedding technology, there are too many hurdles to uses custom type faces on your website. You can use Photoshop created text graphics, and there are some tools to help make using custom typography on the net easier, like sIFR (which relies on the Adobe Flash Player). While these are creative solutions, they are pretty restrictive – limiting the use of fonts to small blocks of text, like headers. They can also be time consuming to set up, and there is no way for web page designers to use these techniques for body copy. So other than some sparse use here and there, web designers don’t even consider using – or licensing – fonts for web sites, and instead stick with the same 10 fonts that most people have on their systems already.

Just as in print, or with photos or body copy, or any other licensable content, it’s on the shoulders of designers to make sure they are abiding by their license agreements. License templates exist that give designers the right to embed fonts in PDFs and other forms of distributable electronic document, and it’s generally well understood that the rights to images found on a web site belong to the owners that web site. When there are violations, friendly notices, or nasty-grams from the layers, seem to do the trick to get things resolved. These same principles undoubtedly apply to embedded fonts, and are no more complicated. Those are the solutions to possible abuse.

If we must though, I would suggest a move to a middle ground, and follow the example of the natural restrictions placed on photos. Since photos are reduced in quality and in size when converted to jpegs, re-use is impractical for high quality output. So browser producers could consider a special, difficult for end users to install font format for embedded web fonts, something based on SVG maybe. This would probably be a good idea for a number of reasons anyway, including smaller file sizes and better cross platform compatibility. Fonts could then be converted and subsetted for use in web pages, in the same way that they are converted and subsetted for use in other web distributable formats, like Adobe Flash, Director, PDF, and Silverlight.

I hope Opera CTO HÃ¥kon Wium Lie will stand by his publicly stated desire to see embedded web fonts come to Opera, and that something like that might be the catalyst that gets the other browser makers moving on embedded fonts.

I think the time has long passed for embedded web fonts.

 

Embedible web fonts and the rights counter argument

Gah! I’d like to apologize to anyone who received a ping of a very early draft version of this post, or had to suffer through that unfinished thought dump or any of the hurried revisions in between.

I’ll post the finished article in a little while.

I hit the publish button accidentally on my way to click the File menu in Windows Live Writer, and the thing published without warning. Time for a feature request – either warn before posting by default, or move the publish button to a less accident prone location.

Update: I posted the finished article.