Archive for July, 2008
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.
Quick pointer to tomorrow’s hackmeetup in Malmö: http://upcoming.yahoo.com/event/921335/. Yours truly will be doing a very speedy version of my sIFR talk at Singularity, hopefully combined with some weird JavaScript hacks.
Unfortunately, sIFR 2.0.6 did not resolve all issues. Please use sIFR 2.0.7 instead.
sIFR 2 fails to detect the Flash 10 player, and therefore falls back to normal HTML text. This has been resolved in sIFR 2.0.6.
If you are upgrading from sIFR 2.0.4 or older, you must upgrade the sifr.js JavaScript file and re-export your sIFR Flash movies using the sifr.fla file from sIFR 2.0.6.
If you are upgrading from sIFR 2.0.5, you must upgrade the sifr.js JavaScript file.
Detailed Description
sIFR 2 uses the same Flash detection that was originally used in its precursor, IFR, back in 2004. Unfortunately this detection script only expected single digit Flash versions, so it fails to detect Flash 10. This has been fixed in sIFR 2.0.6. Thanks to Giancarlo Gomez for pointing out the problem with the Flash detection.
