Web Fonts, Licensing and EOT
Over on the IEBlog, Bill Hill recently posted about Font Embedding on the Web. In it, he discusses how Microsoft has submitted it’s Embedded OpenType (EOT) file format to the W3C for standardization. This could be an important development for web typography, and here’s why.
Web fonts as currently implemented by Safari 3.1, and supposedly supported in Firefox 3.1 and Opera 10, work by linking to the original TrueType Font or OpenType Font files on a web server. For all intents and purposes, this comes down to distributing a font file. In the case of commercial fonts, this is most likely a violation of the license agreement for the font, which means that you, as a web designer, will get your ass sued.
EOT, however, was designed to enable you to use TrueType or OpenType fonts on the web, without getting your ass sued. Quoting from the W3C submission:
Most commercial fonts have an end user license agreement (EULA) which specifies the rights a person who has purchased a license to use the font may enjoy. As the right to freely distribute the font to others is not normally granted, being restricted to installing within a limited set of parameters, there exists a need for a mechanism to allow people who have licensed the font for use with their documents a way to also use the font for their web content without violating the EULA agreement which they have accepted. The EOT file format was developed by Microsoft in cooperation with font creators for just that reason. The technology has been accepted for use by font makers for over 10 years.
EOT respects the flags in font files regarding embedding and can be limited to domains or full URLs. Another important feature is that it is able to compress the font data and lets you pick the glyphs you want to use – resulting in much smaller files than directly linked TrueType or OpenType fonts.
I believe this is a good, practical solution for having real web typography, which performs well and doesn’t violate font licenses. Some steps still need to be taken, obviously. First of which is cross-browser support for the EOT format, which should be in reach if EOT is accepted by the W3C. Another problem with EOT currently is that the software to generate EOT files is specific to Windows. However, given open formats, that’s a problem that can be overcome as well.
As, apparently, with every Microsoft announcement, there’s plenty of Microsoft bashing being done. Most of the bashing revolves around Microsoft pushing another proprietary format, people not being willing to respect licenses on typefaces, and a feeling that commercial fonts aren’t worth using anyway. I’ll let Chris Wilson reply to this:
As I also stated to the WG - I don’t personally even care that much if that system is EOT as it is today; I’d be okay with building a new system if the details of EOT were a sticking point. But I want to use commercial fonts on my web pages, I want that to work interoperably across browsers, and I want to not have to violate my license for the fonts I use (and get sued for it) in order to make that happen. A solution that only works for freeware fonts is not a solution.
Well at least they are discussing the issue. Personally I think EOT is clever, but it will never work if it was open sourced and there is the dilemma.
But fontface and opentype/truetype embedding is at least possible now, the cat is out of the box. I guess the foundaries is going through a tough time. But I know that FF have some sort of system that prevents sharing fonts. Im not sure how it works, but its there
Thanks for the update Mark :-)
sFIR is not a solution, just a wicked way to turn my fans on
Esben Thomsen | 24 July 2008, 22:07 | link
Esben,
Why would it “never work if it was open sourced”?
Scott Cranfill | 6 August 2008, 16:08 | link
Because encrypting the fonts just creates a bunch of other problems! Its not the way to go in any direction.. and why MS is holding their hands over foundries I seriously don’t understand. Another thought on why open sourcing the encryption properly wouldn’t work, is the lack of commitment from the foundries.
Perhaps it won’t be easy to get access, but the idea itself makes the foundries nervous, since their business is in such a decline.
Esben Thomsen | 7 August 2008, 13:34 | link
Creates other problems like what, exactly? What do you mean, Microsoft is “holding their heads over foundries”? Microsoft is trying to provide a MORE attractive solution to foundries, and it IS more attractive. It’s much more secure than just linking to a complete font file sitting on a Web server. Hopefully, this will become a standard, other browsers will adopt it, and foundries will jump on board. What reason do they have not to?
Scott Cranfill | 7 August 2008, 14:22 | link
This comment refers to your page http://novemberborn.net/javascript/memory-leaks-gone, but the comments on that page are closed.
The “memory leak” that some of the posters there refer to about copy and paste no longer working is probably not a memory leak. It is probably exhausting the desktop heap. Google the term sharedSection to see how to solve it.
Greenville IT Support | 13 August 2008, 06:52 | link
@Greenville, that’d make it a more generic OS issue then?
Mark Wubben | 13 August 2008, 13:20 | link
Finally, it looks like MS is doing something right, then?
Josh | 15 August 2008, 19:43 | link
Unless I’ve completely missed the point, it seems to me that Microsoft are keen to provide a DRM-enabled system for the font-industry.
Why? If they can prove that DRM can work for fonts - maybe it will help to promote their efforts to protect other forms of media using DRM-based technology.
I don’t believe that DRM works for music, and I’d be highly surprised if it worked for fonts. In my mind it’s flawed because, by it’s very nature, DRM has to rely on proprietary code and techniques.
Apart from issues associated with lack of openness and platform compatibility, sooner or later the companies which provide the technology go bust or stop supporting the technology (see msn music for an example).
Cynically, I’d say that the whole DRM scene is simply about old school companies wanting to create new sub-markets, where they can slice revenue from other industries .. and I think this a bad thing. I think this is just another example of that.
luke | 17 August 2008, 21:18 | link
In the case of EOT, the font licensees themselves apply the DRM, to uphold their license agreements with the type foundries. License agreements they need in the first place, in order to legally use the type face. This is much unlike the DRM we’ve seen applied to music and DVDs etc, where the DRM is imposed and is on a mass scale, attempting to protect – and failing miserably – content from being copied by the end users.
Unlike with DRM’d music, the license taker is not the person who buys the track or visits the website: it’s the company that uses the font. You as a visitor to the website are no party in the agreement between the licensee and the font foundry.
Will this stop the illegal distribution of typefaces? No. Will type foundries eventually face up to that? Maybe. In the mean time, does this provide a way for licensees to legally embed typefaces as real text in websites? Absolutely.
That can’t be bad.
Mark Wubben | 17 August 2008, 22:58 | link
@Mark
I understand your points more clearly now. However, I still think that EOT proposes an over-engineered and ineffective solution.
To be effective, EOT is going to need to be implemented on a mass scale. For all browsers to use EOT, the technology will be need to be open. Once the routines used to encrypt the font files are public knowledge, those who are willing to, could potentially reverse the encryption.
So Microsoft’s W3C Member Submission goes on to suggest two further technologies to help protect the font. URL binding (which ensures that the font file is only usable from specific document roots) and subsetting (which pre-selects characters based on their use in the target document).
Subsetting seems the most problematic to me. The web (obviously) isn’t the same as print, because it’s dynamic. What happens if we choose to use an EOT font in a wiki? Or if a Norwegian visitor wants to write his name correctly, and the EOT routine hasn’t imagined this possibility?
Microsoft might respond by saying that designers don’t need to use subsetting in all cases. If this were the response, I’d wonder whether subsetting would ever be used.
I’m very much in awe of the amount of effort that goes into creating quality type, but I still don’t think that prohibitive technologies like EOT are sensible.
Without EOT, any illegal use of type is still highly visible, because typefaces are openly published by the sites that link to them. I think that font foundries just need to work out a method to let site owners publish information about their purchased licenses. Catching sites without licenses would then be fairly easy - and ultimately more people would pay for type.
In my mind, all of these issues ultimately come down to a philosophical battle. Piracy is painted as an activity driven by greedy consumers, trying to get a free lunch; but I think it’s the corporations expecting perpetual financial gain from intellectual property, who are ultimately corrupt.
luke | 18 August 2008, 10:42 | link
This is quite likely. It’ll have to be seen how easy it is to go back from EOT to True- or OpenType.
URL binding may be very easily overcome. Sub-setting is not really a security measure, but a way to decrease file-size. Flash, and therefore sIFR, works in the same way. You are correct that this can be a problem when an unexpected character ends up being used.
A good use-case for sub-setting is a website where an EOT (or sIFR) font file is used only for all-caps text. Removing the lower-case glyphs will (roughly) halve the file size required.
EOT doesn’t solve this problem either, except in a minor way that font files that have not been flagged as appropriate for embedding cannot be embedded.
Agreed.
Mark Wubben | 18 August 2008, 13:43 | link
To #6, Mark.
The reason that I posted here is that I wanted to add a comment to the original post about memory leaks that I thought could be useful to people who arrive on that page through a search engine.
Since comments are closed for that page, I wanted to place a comment on this blog so that the blog poster, if he chose, could replicate my comment, or move it to that page to be of assistance to people who do find that page through a search engine. Believe it or not, I’ve actually know bloggers who will do that to try to help their readers.
This post was a fairly recent post at the time I posted #5 above and I hoped the author of the blog might return here, see my comment, and make a useful update on the original page.
I did not pick this page because it was relevant to the original post that I mentioned. I picked this page because I thought the author might see my comment. I thought that would be self-evident from my post what my purpose was.
Greenville IT Support | 14 September 2008, 17:13 | link
Mark.
I just realized that you are the author of the blog.
When I read your comment I thought you were just someone posting here and that you were complaining that I made my comment here instead of in some other post.
I realize now that I might have misunderstood what you were saying, and I apologize if I misunderstood your meaning.
Greenville IT Support | 14 September 2008, 17:22 | link
No worries. Perhaps though it’d be an idea to try contacting the blog author rather than commenting on another post ;)
Mark Wubben | 14 September 2008, 19:37 | link