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).
