Web Fonts
There has been a lot of recent discussion about the possibility of web pages containing embedded fonts. The professional type design world has been relatively silent on this issue. That’s probably because there are significantly fewer of us than there are web designers. As a type designer who understands type technology, I thought I’d break the silence and offer my own thoughts on this issue.
Note: These are my views. They do not reflect the views of my clients, my colleagues, my friends, my family, my company or, if you want to argue, me. Also, these are my current opinions. I reserve the right to change my mind.
First a little background. In August of 2007, Håkon Wium Lie published a proposal for embedding fonts into web pages on A List Apart. (Full disclosure, I emailed Håkon shortly after he published his article. Our email exchange resulted in another proposal to improve typography on the web.) The WebKit team implemented Håkon’s proposal shortly after it was published. The web erupted in cheers and more than a few shouts along the lines of “Down with the monopolistic font industry!” Apple has announced that this will be a feature of Safari 4. From what I gather, other browsers are working on their own implementation. There was a W3C member meeting to discuss this. It has been a fast period of development that has opened up several cans of worms of the technical, legal and ethical variety. That’s where we stand now.
The W3C has a proposal for a working group that will address the various issues that have come up, but it has not yet been started. Unfortunately, at this time, there doesn’t seem to have been much input from people who actually make the fonts that these folks are discussing. I looked into joining the W3C so that I could contribute to the group, but it would cost $7900 per year for three years ($23,700 total plus the expenses of traveling to meetings). Based on my reading of the charter, it looks like the discussions will take place behind closed doors. This is quite depressing.
There are relatively few type designers in the world. (If you doubt me, think of all the type “foundries” you know of, go to their websites and look at how few type designers actually work there. Shocking, no?) There is no “type industry”. We have no lobbying group. Anyone who claims to represent the “industry” probably has a bridge in Brooklyn to sell you as well. We haven’t had much of a voice on technical matters in the past. We’ve had to roll along with whatever the OS vendors will support. Essentially, we’ve been told that we have to rely on the honor system as the basis of our livelihood. That’s where the small number of type designers there are stand and it is where we have stood for a long time. We’re constantly under threat of having the technical rug pulled out from under us, but we keep going on because this is what we have been called to do. So, here we are.
I’m excited by the possibilities of web fonts. I see this as the future of type design. This will be great for web designers and, above all, readers. It will be great for companies that commission custom typefaces who want to extend their branding to their websites. I think this could be done in a way that honors all of the work that we’ve done to create the fonts that people want to use. I think this can be done is an easy to implement, backwards compatible, shady-DRM free way that gives everyone what is being sought.
Enough with the moving soliloquy, time for the details.
The Current Proposals
Raw TrueType/OpenType: Håkon Wium Lie has proposed using raw TrueType and OpenType files. His justification is that there are quite a few free fonts that can be used for web pages. These fonts already exist, so they should not have to be modified to work.
EOT: This is a font format that was developed by Microsoft. It seems some of the browser manufacturers are very resistant to EOT.
Root Table/New Web Font Format: Sampo Kaasila proposed an extension of the OpenType (and therefore TrueType) specification. This would create a new font format specifically for web embedding. However, it wouldn’t be completely new since it would simply be OpenType with a couple of new things. Specifically, these are the changes:
- A new “root” table that would contain a string that ties a font to a specific domain. When a browser downloads a font, the domain that the web page belongs to will be compared to the root table. If they don’t match, the font isn’t used.
- The first 100 bits in the font data would be obfuscated to make the font data unique from an OpenType font.
Additionally there has been discussion about referencing and honoring the fsType embedding bits in the OS/2 table.
My Thoughts
Overall, I see Håkon’s point on the free font issue. However, this will unfortunately put type designers into the role of license police. If someone can take one of our fonts, put it in a freely accessible directory on their server, that’s a violation of most of our license agreements. We’re going to have to spend a considerable amount of time trying to catch this when it happens. I don’t think any sane person is looking forward to this. I have a possible solution for fonts that are created in the future, which I’ll explain below when I discuss embedding bits below.
Personally, I really like Sampo’s root table proposal. It is a very elegant solution that builds on solid technology and wouldn’t require a lot of extra work for the browser developers. It would create an opportunity for type designers to license fonts to specific websites. That’s a win-win. There are a few things I’d like to add to this:
- There should be a way to specify “all domains” in the root table. This would, again, be useful for free, GPL, open source, etc. fonts.
- There should be a way to specify “no domains” in the root table. This wouldn’t have any immediate value, but it seems logical that if there is a way to specify “all” there should be a way to specify “none”.
- Web authoring tools should not create a web font from a raw TrueType or OpenType font. They should not modify existing root tables. I have a feeling that this will be addressed in EULAs, but it should be common sense that tools shouldn’t change the embedding settings in a font.
- There should be a new file extension for this. I propose “.wtf” - “WebType Font”.
Embedding Bits
I’m happy to see that there is some interest in honoring what the designer has set. However, there is a problem with referencing these bits for info about web embedding restrictions. Most of the designers I know consider these to be PDF embedding bits. The OS/2 specification isn’t clear about what these bits should be used for, but that’s what we all seem to think. This is an important distinction because if we don’t allow PDF embedding we can cause major problems in print workflows. So, we have to set our fonts to at least “Print and Preview” embedding to enable graphic designers to do their jobs. This is not the same as allowing “Print and Preview” embedding for web pages. The embedding bit situation is a mess. There are proposals, such as EEULAA, that attempt to make this more clear, but I don’t think those will clear the major hurdles they face before the web font discussion draws to a close.
Given all of this, It would be great if a new bit could be added to the fsType bits that would let us flag a font as eligible for web embedding or not. This bit could be added to the OpenType 1.7 specification. For this to work, a browser would look at the bit in the table and determine if it is eligible for web embedding or not. The touchy side of this regards fonts in format 1.6 and earlier. As it stands now, Apple and others have browsers that handle raw TrueType and OpenType fonts without any regard for embedding bits. If browsers require fonts with format 1.7 or higher, old free fonts won’t work and users of Safari and others will see different rendering results for pages that already have embedded fonts. Users will be sad. If the browser doesn’t require 1.7, it means that existing fonts that aren’t intended for web embedding have no protection. Type designers will be heartbroken. I don’t know what the solution for old fonts is. I do think that a new bit will help with new fonts. This would be a simple, workable solution to the problem with the raw font file proposal I mentioned above.
“But People Will Hack Commercial Fonts”
Yes, they will. There is nothing that can be done about this. All we can do is present a person with a fork in the road. The person can license the font to give the designer the respect he/she deserves for creating something that the person likes and wants to use. Or, they can ignore the Golden Rule and hack the font. There is no way to prevent this other than relying on a shared hope that people will be nice to each other. The last ten years have proven that there is no encryption that can’t be cracked and that there is no complex format that can’t be parsed.
How will this work in practice?
I don’t like to predict the future, but here’s what I think could happen: Say you have a blog and you want to use a font from the XYZ foundry for headlines on your site. You go to the foundry’s website, you enter the domain that your font will be used for, you buy a web embedding license for a small fee, you download the web font file and you put it on your site.
In Conclusion
That’s all there is to it. Two formats: Sampo’s web font format and Håkon’s raw font format. One simple change to the OpenType spec: a new bit in OS/2 fsType for specifying if web embedding is allowed or not. Off we go into the future.
I think this is a good compromise. Each side wants certain polarizing things. I think what I’ve outlined above is a good middle ground. At the very least, I hope type designers get to be a part of the discussion.
Paul Bukhovko has translated this post into Belorussian.