@font-face in IE: Making Web Fonts Work

All Hallows’ Eve seems the perfect time for something a little spooky. Getting @font-face working in IE may just be spooky enough. As you probably know @font-face already works in Safari 3 via WebKit and is supported in the latest Firefox 3.1 beta. With IE, that means around 75% of the world audience could see custom typefaces today if their EULAs allowed it. Fortunately, there are good free faces available to us already, as well as some commercial faces that permit embedding. Fontin is one of them and I’ve built it into this example page:

@font-face test with Fontin by Jos Buivenga

See the full size Safari 3 screenshot, IE7 with ClearType, and IE6 without ClearType screenshot on Flickr.

Before we get into the nitty-gritty of making this work, which you can skip to if you wish, I thought a little history and a brief summary of the current status of the web fonts debate might be useful.

Web Fonts: Then & Now

Web fonts have been with us for a decade. They were an original part of the CSS2 recommendation in 1998. Recently, the godfather of CSS, Håkon Wium Lie, brought them sharply into focus with articles in CNet and A List Apart. The ironic thing is, IE has supported web fonts using the Embedded Open Type (EOT) format since 1997. The problem was that EOT was a proprietary format, belonging to Microsoft. Not for much longer: it’s been submitted to the W3C and is going through the process towards becoming a web standard.

Since the debate opened up, the web and type communities have both been busy discussing how the future will unfold. More collaboration between the disciplines would be beneficial to both, and I’d encourage any interested designers or developers to get involved with organisations like the Association Typographique International (ATypI).

Recently, Bert Bos of the W3C paid a visit to the ATypI Conference in St Petersburg to meet with type designers face to face. His summary of the current situation is essential reading. The debate has continued apace on the ATypI mailing list, which unfortunately has no public archives. However, if you are member of the ATypI, you can see this summary about the conference panel on web fonts by Nadine Chahine that started the debate in earnest. Simply put, type designers seem anxious about @font-face linking making it too easy to steal a font. Both Microsoft’s EOT format and direct font linking are under consideration with EOT a favourite with many. However, rather than paraphrase a wide-ranging set of opinions, I’d encourage you to join the ATypI yourselves as designers and developers to participate or observe.

If you have other favourite comments or posts about the future of web fonts, please add them to the comments.

As a designer, I want a straightforward way of licensing and including fonts for my work. I will pay, respect the rights of type designers as I expect mine to be respected, then get on with the glorious business of merging content with type. It’s not as simple as it sounds, though. The licensing of fonts, and the protection of the rights of smaller designers in particular, is a sticky issue. DRM does not work, so what then? Richard Rutter has shared thoughtful insights which are very much worth a read. My view is that I would be perfectly prepared to pay a separate or extra licence fee to use quality fonts on the Web. I would have no problem selling this to my clients. Embedding or linking to fonts has to be straightforward though. I get paid to think about, plan and implement design, not grapple with obstructive software (more on that later). If fonts were delivered through a third-party web service as Richard suggests, the one proviso must be that it would have to be done by someone who knows exactly what it means to scale a service for millions of users. Like most designers though, I have very little knowledge of the real security and scalability issues, but hope to see a comment from a real security expert, shortly.

User agents are currently taking divergent routes. Bert Bos’ summary reports:

Mozilla has stated that they don’t want EOT. But they are not opposed to letting the browser check the license, as evidenced by the proposal to let HTTP headers carry license data.

Microsoft has said that it is impossible for them to support linking to native OpenType as long as font vendors oppose it.

Apple’s Safari has implemented font download with no checking of licenses. They said they are against EOT, but would not be against browsers checking licenses, e.g., using Mozilla’s proposal.

Opera remarked that there are more existing and announced implementations for downloading native OpenType than for EOT. They conclude that the market apparently doesn’t need EOT and thus they see no need to support it themselves either. W3C’s limited resources should be spend on more important standards.

That means that designers and developers have the same perennial problem: Two different implementations to achieve the same result. Safari 3 and Firefox 3.1 beta both support direct linking to OpenType (.otf) font files. Presumably Opera will soon. Only IE 4 to IE 7 support Embedded Open Type (.eot) files. IE8 does not, but will at some point. So, to see Fontin display in standards complaint browsers like Safari 3 and IE, we need to provide two separate fonts.

@font-face Example

The @font-face example uses Fontin Regular by Jos Buivenga — a free face kindly provided by Jos with a licensing permitting embedding with attribution. Jos also has many other fine faces available via his foundry site, Exljbris. The example is a quick one using a traditional scale, with all of the CSS available in the <head> of the file.

Set the basic font-family:
```
h1, h2, h3, p, td{
font-family:'Fontin-Regular', georgia, serif;
}
```
Notice the 'Fontin-Regular' name — this is an arbitrary name that can be whatever you like. All it does is tell the browser when to apply the font file referenced in the @font-face rule.
@font-face and .otf for standards compliant browsers:

Ed: White space inserted for clarity.
```
@font-face{
font-family:'Fontin-Regular';
src: url('Fontin-Regular.otf') format('opentype');
}
```
Note the 'Fontin-Regular' name, again. This rules basically tells the browser, when the @font-face is set to 'Fontin-Regular', use the font found at this URL.

Screen sample of Fontin Regular in Safari 3 set at 16px with 24px line height from the example:

When Safari renders the page, it will look for the font file, then render the text accordingly. There’s a slight delay as WebKit works. In the example you might notice that the text not requiring the loading of a font file renders quickly, but the rest is blank until the browser catches up. For reference, the Fontin-Regular.otf file is 32KB in size. Some font files can be much larger.
Create the .eot file with WEFT:

To do this you will need to download and install WEFT3, a Microsoft application for creating EOT files from TT fonts. WEFT is not able to create EOT files from an OTF. It must be converted to a TrueType file, first. WEFT is the only tool for this as far as I’m aware, although I believe there is an open source one in development. If it wasn’t for WEFT, embedding EOT files would be easy. What I want WEFT to do is convert the font to EOT, and allow me to create a subset if required. It does that, but in a nightmarish, frighteningly over-complicated way. Perfect for an All Hallows’ Eve entry. Here are a few tips I learnt the hard way:
1. WEFT requires the URL of the page or site where the EOT font will be used. It will then ‘scan’ the pages by crawling the site to see what glyphs are used and try and create a subset of the EOT file accordingly. If it refuses to analyse a valid URL as it did for me, get granular and specify pages or sub-directories in your information architecture.
2. If you’re using WEFT via Parallels and XP Pro, it may refuse to add some fonts in your windows/fonts directory to its database of available fonts. Try using a standalone PC if you can. I haven’t tested in any other virtual machine.
3. Use the wizard to set up your project, but after that try it manually using the View menu item to see what fonts are available to convert, and the Tools menu item to convert them.
4. WEFT will try to save the EOT file to a remote location. You can over-ride this manually to save the file wherever you please for you to upload yourself.
5. Disable your original OTF fonts on your system before testing (obvious but worth a prompt).
Be warned, WEFT is awful to use, in every way. ~~It did not work for me running Parallels with XP Pro on a Mac.~~ 7th Nov: After more experiments, Weft will accept TrueType (.ttf) files in Parallels. It also worked with the gracious help of Jon Gibbins and his standalone PC running XP Pro. Because it is so painful, I cannot give support for WEFT. You can try the Microsoft WEFT user community, but I can’t comment as to its usefulness, and I could not find any other support avenues.

Hopefully, you now have an .eot file to use.
@font-face and .eot for IE using conditional comments:

Ed: White space inserted for clarity.
```

```
These are screen samples from IE:

Screen sample of Fontin Regular in IE6 set at 16px with 24px line height from the example:

Notice the bar missing from the capital ‘A’ towards the end of the second line. The tyepface designer, Jos Buivenga is currently looking into the font hinting, with input from John Boardley.

IE7 sample:

See a full size Safari 3 screenshot, and IE6 screenshot on Flickr.

That’s all! Try the example in different browsers to see how it works for yourself (but please don’t blame me for ClearType’s poor anti-alias at larger font sizes).

Summary

We have only a few web fonts with a EULA that permits embedding right now, unless they are free. Please respect the EULAs of any typefaces you try out until the type community resolves the issue for all commercial fonts.

My feeling after doing this is that EOT has potential advantages in file size over OTF, but OTF files could always be edited (as far as I’m aware) to create subsets just like EOT. Although EOT is not a DRM solution per se, it feels like one. If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long.

What we need to encourage designers and developers to use EOT today is a good tool to create EOT files in the first place. Perhaps even one hosted remotely, where we can buy a licence, convert the font to EOT, grab the same OTF subset for complaint browsers, and get the work using the typefaces we’ve always dreamed of. WEFT is not the tool right now to enable EOT usage. In fact it discourages it.

Regardless of what security is implemented, the font file will have to be on the audience’s machine somewhere, even temporarily. ‘Defense in depth’ is a term used by web app security experts. It would seem that the question is how much depth will satisfy foundries and type designers, and what form that depth will take.

As a designer, I can only speak for myself to say that if OTF and TTF were supported, regardless of how easy it was to steal the file, I would still pay as required by the EULA. I have a strong feeling the vast majority of my colleagues feel exactly the same.

64 Comments

1. By johno on 31st Oct ’08 at 10:58am

There’s a lot of work behind this article. Great job, Jon. The missing cap A bar is a strange one. I’m looking into that. Well, you’ve certainly made the whole more comprehensible. Thank you.

2. By Peter Gasston on 31st Oct ’08 at 10:58am

Stupendously in-depth article, Jon; congratulations. As for your closing summary, I agree with you completely.

IMHO, font vendors should learn the lesson of the music and film industries and look not to fight the web, but for ways to embrace and profit from it .

3. By Leon Paternoster on 1st Nov ’08 at 01:32am

You might pay, Jon, as will anyone working commercially, but think of the millions of websites that won’t. Of course, there’s nothing to stop people downloading illegal copies of fonts at the moment, but this will just make it more desirable, and easier, to do so.

Still, this looks like it’s going ahead in some form or other. I must admit that I’ll miss working with such a small set of fonts: I feel it’s really focused my web typography. I guess we’ll see some pretty horrendous/illegible combinations.

Sorry to be a typo PITA again, but who’s is wrong in the first line of your summary.

4. By Ray on 1st Nov ’08 at 02:29am

The subject of web fonts is dear to my heart. Web fonts/@font-face/font embedding/whatever you wish to call it is a promising technology—and has been, as you write—for over a decade. You clearly understand a good deal of the history of the subject but saying “please respect the EULAs… until the type community resolves the issue for all commercial fonts” seems to ignore this history of font embedding; or at the very least, the length of this history. To characterise the movement of all the actors involved as “sluggish” is an insult to slugs.

I’m not suggesting that designers pursue illegal activities with the usage of fonts. But a “wait and see” approach will only contribute to the general lethargy of the actors. The only real reason why there’s been any real movement on the use of @font-face (I feel) is because of the Acid3 test, which requires the use of @font-face. If the Acid tests have done anything, it’s been to spur developers into swifter, more mutually-beneficial action & is therefore praiseworthy.

As for the missing “A” bar in WEFT-created EOT files (and for using WEFT in general), I sympathise with you. I had very similar problems (cited in the article above) & it seems to be an issue with the font itself, not necessarily with WEFT.

5. By Jon B on 1st Nov ’08 at 04:16am

Firstly, thanks for some further insight into this (especially WEFT which I’ve tried to use several times and always ended up scratching my head and wondering why it isn’t just a hell of a lot easier – afterall, all an EOT needs is a font file, a domain, and the characters you want to include in it – why did MS make that so hard!)

Like others I share concerns of 'stealing' fonts, not that I make any myself, or am in a position to pay large fees for using them – but there is a lot of 'stolen' work on websites which never even gets attributed (icons, images, text, and soon fonts it seems) However I am not so taken with EOT, purely because of the complicated time consuming process (and lack of support obviously). There has been suggestions by various people of creating centralised 'font pools’ for web fonts, and that this could be the future of font foundarys, which as I understand for now firefox 3.1 would be the only browser to support (I think, as it can do HTTP license checking?) To me this would be a great solution, fonts are managed by account, you pay to add domains to them – and they are served by fast servers (I’m not entirely sure how fonts are cached, but this could be a bonus too) This method could also work with EOT, with the foundary automatically creating appropriate EOT files and serving them in the same way. Safari can loads fonts from any domain and doesn’t check licenses – but potentially with a bit of referer checking this could be handled too I’d imagine (until they get up to speed) So my thoughts are that font makers should look to this as a good thing and work on ways to monetize it quickly before they miss out.

6. By Jon 陳 on 1st Nov ’08 at 06:35am

Thanks for all of your contributions, it’s great to get these kinds of quality insights from colleagues. Something I want to add here is that I think there are three other critial elements to improving web typography:

1. A grass roots, standards-driven movement to identify and curate an enhanced set of core web fonts. They would include much better type style variants. They would be paid for by a mixture of sponsorship, public funds and grass roots donations allowing an organisation to commission type designers at commercial rates. Lastly, and critically, they would be delivered freely with operating systems under agreement with the companies involved. N.B. Internationalisation is imperative in any future development of enhanced core web fonts. Universally available, platform-independent, high-quality system fonts would be the goal.

2. CSS to develop in line with OpenType tags to enable control of advanced typographic features in user agents like ligatures.

3. Rendering engines to do a better job of rendering fonts supporting the full range of subtlety that can make or break typography on the screen such as hinting, anti-alias, kerning, ligatures, hyphenation, etc.

7. By westworld on 3rd Nov ’08 at 05:02am

Maybe font companies could host a web version of the font’s that they are selling.

Stuff like a full open type version, a version stripped of non English characters, a bold and an italic version. People could then link to these and only get access if they payed (you could do this based on serverip for example).

Popular fonts could even be in the visitors browser cache

This helps web designers who don’t have a clue about fonts. Imagine sending a full Vandekeere to you visitors while the page only uses 20 glyphs. Just because you dont have a clue how to remove unused ones.

Letting someone else host the font is also good for speedy download. If my memory serves me, browsers only take two simultaneous downloads from one domain.

just my 2 cents

8. By Jens Meiert on 4th Nov ’08 at 03:43am

Nice round-up, however I may note that Conditional Comments still have a negative impact on maintainability (even amplified by using style elements instead of external style sheets, as in the example), and thus caution yet patience seem to be quite recommendable I fear.

9. By ST on 4th Nov ’08 at 10:10am

Your example: (link – converted to proper hyperlink by Ed.)

In firefox looks like its defaulting to georgia?? Not working in firefox, seems to work in Safari though~

10. By Jon 陳 on 4th Nov ’08 at 12:02pm

ST, it works in 3.1 beta as the article mentions. I assume you were using an older version? Please re-read carefully and, if you find a problem, please be specific with the browser version number to help debugging. Many thanks.

11. By ST on 4th Nov ’08 at 17:55pm

Ah, my mistake!! Thanks for clearing that up, my version of Firefox was 3.0 X-p

Great article by the way, it had me experimenting all morning! Thank you Jon!

12. By Robbie on 9th Nov ’08 at 21:06pm

I’m not seeing Fontin with Firefox 3.1b1.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1

It is working in IE 7 on the same machine.

13. By Jon 陳 on 10th Nov ’08 at 01:15am

Hi Robbie, it seems to working fine with 3.1b on OS X. Has anyone else tested using 3.1b in the context Robbie has posted?

14. By Jon Gibbins on 10th Nov ’08 at 02:36am

If anyone is interested on trying WEFT on a Mac, when running on Windows XP using VMware, WEFT doesn’t seem to pick up on installed fonts. Parallels does appear to work. Just remember that WEFT will not pick up on OpenType font files installed in your system Fonts directory, only TrueType font files.

15. By Robbie on 10th Nov ’08 at 10:38am

@Jon I did a quick test on OS X with FF 3.1b1 and the test page worked fine. Must be isolated to the Windows version.

16. By Ralf Herrmann on 11th Nov ’08 at 13:51pm

PostScript-flavoured OpenType fonts are not working in the Firefox beta in Windows (TrueType do work). It’s a known bug and will get fixed.

17. By Charles Cooper on 13th Nov ’08 at 07:17am

This seems like it sould be easy to do, and I thought I’d give it a try, but it doesn’t seem to work. Anyone able to suggest where I’ve gone wrong?

I can view all samples posted at the referenced link (A List Apart), so based on a quick reading, I thought this stripped down pagelet should work.

Any suggestions, anyone?

I’m viewing it on XPpro, SP2, using IE6 (yes, I know), FF2.X, NS9, Opera 9.61 and Safari 3.1.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" > <head> <style> h1{ font-family: "Fontin-Regular"; } @font-face{ font-family: "Fontin-Regular"; src: url("http://www.rockley.com/chamber/fonts/Fontin-Regular.ttf") format("truetype"); } </style> </head> <body> <h1>this is Header1</h1> This is Paragraph text </body> </html>

It’s probably something embarrassingly obvious – and I’m willing to be embarrassed if it helps me learn!

18. By Jon 陳 on 14th Nov ’08 at 02:28am

Hi Charles. Which browsers specifically does it not work in? Is it all browsers? Your example worked fine for me with a quick test in Safari 3.1.2 / OS X.

I’ve cleaned up you comment and removed multiple line breaks from the example. As you’ve probably guessed, my home-rolled app is not built to handle multiple lines of code in comments (hence the lack of a pre tag in the style guide). You may wish to consider putting examples on your own domain and linking to them. Cheers!

19. By Ralf Herrmann on 14th Nov ’08 at 03:26am

I’m viewing it on XPpro, SP2, using IE6 (yes, I know), FF2.X, NS9, Opera 9.61 and Safari 3.1.

Look here:

http://www.webfonts.info/wiki/index.php?title=%40font-face_browser_support

Of all the browsers you mentioned only Safari 3.1 currently supports direct linking of TTF/OTF fonts. It also won’t work in the upcoming Firefox 3.1, since you used an absolute URL to the font file.

20. By John on 14th Nov ’08 at 11:56am

OTF-Support for Firefox 3.1ß1 under Windows is broken for the moment.

Windows: Postscript-style OTF fonts (i.e. CFF fonts) don’t load [bugzilla]

21. By Charles Cooper on 14th Nov ’08 at 12:53pm

Jon – thanks for cleaning up the code. I appreciate it. I’ll link future code snippets to my own domain as requested.

It doesn’t work with any of the browsers mentioned in the initial post.

Ralph – thanks for the link to the supported browsers. Appreciate it.

John – thanks for the link.

Too bad. It looked like an easy way to support simple font changing for titles and such.

Presumably if I used parallel declarations for Safari 3 and FF (.otf) and IE4/7 (.eot) it would work, but not with TT in the foreseeable future due to the number of people using old browsers.

Is that a reasonable assumption?

coop

22. By Ralf Herrmann on 15th Nov ’08 at 00:08am

Presumably if I used parallel declarations for Safari 3 and FF (.otf) and IE4/7 (.eot) it would work, but not with TT in the foreseeable future due to the number of people using old browsers.

Sure it works with TT. Safari, Firefox 3.1 and a future version of Opera will all support TrueType, OpenType TT and OpenType PS fonts.

It you put an addition EOT font in your @font-face declaration you will also support IE users since version 4.0!

(By the way: EOT is nothing than a TrueType/OpenType font within a wrapper)

23. By Charles Cooper on 15th Nov ’08 at 19:12pm

Thanks very much – I’ll give that a try and see how it works.

24. By Patrick Algrim on 18th Nov ’08 at 12:44pm

Awesome write-up. I am really glad to see that people are focusing on the font issues. Typography is such a huge importance when it comes to Web design. I would love to get rid of images all together. Personally, I am not a huge fan of it. I really like sIFR, but I have notice some huge performance issues that can go along with it. Personally, I think this type of embedding won’t take presidency for a little while. It’s still extremely common to be worried about IE 6 and up. It’ll be tricky to get around everything, but it looks like this is such an amazing start! Great job to everyone!

25. By Ben Clarke on 27th Nov ’08 at 08:11am

My favourite bit on the Microsoft typography page you link to:

This technology is changing the look of the Web, by empowering site designers to ensure their pages appear as they want them to. Check out the following examples.

…

this page was last updated 26 February 2001.

26. By Jon Gibbins on 4th Dec ’08 at 05:52am

And so, Opera 10 alpha adds Web Fonts support. So, with Opera and Firefox support on the way, it looks like we should see some action in this area in the not-too-distant future.

27. By Alex on 21st Dec ’08 at 21:34pm

"…If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long."

That happened a long time ago, EOT as it stands offers barely any protection over normal OTF or TTF fonts (It’s up to the browser to respect the domain restrictions, but for browsers to show the font, they have to turn the file into a normal OTF or TTF file and dump it on the file system anyway) Even IE was hacked to dump out the raw OTF/TTF files when it encountered a EOT file.

Basically, you can throw all the DRM you want at this problem, but by the nature of how it works, it can’t be solved in a way that will suit all parties. And I’ll lean towards a solution that annoys some people but makes it easier for everybody, rather than a solution which makes some people happy, but annoys everybody else and makes it harder to use font embedding for no reason.

28. By Jon 陳 on 22nd Dec ’08 at 01:39am

Thanks for he useful additions, Ralf. I appreciate all the work you’re doing in this area. Great to see Opera about to round out the support as per Jon’s comment.

Alex, thanks for your technical insight. Have you any references or links? I agree with you regarding preferred solutions — it’s some of the foundries and type designers who we need to bring with us, I think.

29. By Christopher Olberding` on 22nd Dec ’08 at 14:22pm

Very good and comprehensive article. I admit that I haven’t kept up to developments in this area very closely as it has long seemed that there were too many barriers for opening things up.

Doesn’t really seem like there has been enough progress for me to start getting my hands dirty but I will be keeping a closer watch.

30. By Alex on 23rd Dec ’08 at 14:42pm

Reverse Engineering the Embedded OpenType Decompression

That article is about hooking the core EOT library to get it dumping the EOT data to TTF files, but you don’t need to use that method to get the font info. A EOT font is a normal OpenType font with some extra data, the font data can be compressed or “encrypted” (It’s in quotes since it isn’t really encryption), and the EOT header will say which it is, so any app that loads EOT files without using the MS API (e.g. any web browser not on Windows) will need to decode the font and convert it into an unprotected format, what it does from there can differ (Firefox used to dump all the files to disk, monitor the right folder and you’d see the .ttf files appear during page load, might have changed though).

That you can turn a TTF file into an EOT file, then turn that EOT file directly back into a TTF file seems to make the whole system pointless. It won’t stop anybody actually using the font, but it would stop somebody just downloading the EOT file and trying to use it, which is what they actually want I suppose. But it seems like a whole lot of effort and trouble for little to no protection. I suppose one “argument” for EOT is that there aren’t many tools to do the conversion, but I think that’s just a sign that nobody really cares about the format.

Also, try getting these tools to play nicely with PostScript outline OpenType fonts, WEFT won’t convert it, MS’s EOT API won’t load it, and Uniscribe won’t shape it.

31. By justpassingby on 9th Jan ’09 at 23:57pm

You can download SWF files (and there are commercial decompilers)… Has this stopped the Flash Developer Community from uploading tons of games and stuff?

You would expect that MP3 files are secure on the myspace page of an artist (or their Official Website)… nope… Has this kept them from posting new music?

Difficult age we live in, definitively…

32. By sbs on 3rd Feb ’09 at 13:22pm

what a impressive article. last days I didn' t read post like that. I am now your blog' s follower thanks for this useful blog. you are now in my bookmarks.

33. By Joe Pea on 7th Feb ’09 at 22:53pm

I have firefox 3.1 beta 2 and the font does not appear in the browser on the example page. ???????? Do I have to do something? I would really like for this to work!! This should be standard in web design. I mean if all browsers can handle something as complex as Flash, shouldn’t something so simple as fonts be universally applicable as well? People have overlooked this. Having any site’s custom font should be as easy to display as is Flash (If not, easier).

34. By josh on 24th Feb ’09 at 07:29am

This is a great article, I really appreciate that you covered just about every aspect of making web fonts work on the web in, including the politics. I had no idea that web fonts had actually progressed this far. Even though there are a few problems as you mention, it seems like embedding fonts could become a not too far off technique for web designers.

35. By Alex on 25th Feb ’09 at 18:57pm

@ Joe Pea

Are you on Windows? Because there’s a bug in Windows that means OpenType PostScript fonts (like the Fontin font used on the test page) don’t work, it’s been worked around in Firefox though (as in, works for English text, maybe not other languages) so Beta 3 (when it’s released) should show them fine. Hopefully the core bug will be fixed in Windows 7, but unfortunately that won’t fix the bad anti-aliasing MS applies.

And browsers don’t handle Flash at all, they load the plugin and it renders itself, and personally I view a few lines of CSS as easier than going the whole Flash route (although trying to work out the platform specific font matching rules is a bit strange, especially when they vary on the same platform depending on the font type)

36. By Joe Pea on 26th Feb ’09 at 09:57am

Yeah I tried in in Firefox 3.1 beta 2 and Google Chrome and Firefox 3.0 but the font isn’t visible in any of the browsers. Are there certain settings to adjust maybe?

37. By Webtiful on 1st Mar ’09 at 17:53pm

Great article. I will try it. Thanks

38. By sivas on 9th Mar ’09 at 13:41pm

very good. thank you.

39. By killsifr on 19th Apr ’09 at 04:58am

The example doesn’t work in my Opera 10 alpha. It works in IE7, IE8, Firefox 3.1b3, Safari 4 beta and Chrome 2, all on Windows XP.

40. By yucc on 20th Apr ’09 at 00:05am

It does not work for me with IE browsers (Windows XP), any help will be appreciated!

<blockquote>

<html xmlns="http://www.w3.org/1999/xhtml” xml:lang="en” >

<head>

<style>

h1{font-family: “Fontin-Regular";}

@font-face{font-family: “Fontin-Regular";

src: url("http://jontangerine.com/silo/typography/font-face/Fontin-Regular.eot");}

</style>

</head>

<body>

<h1>this is Header1</h1>

This is Paragraph text

</body>

</html>

</blockquote>

41. By paul on 23rd Apr ’09 at 12:54pm

if you are on linux, you can use ttf2oet script to easily convert a TTF to EOT !!

42. By paul on 23rd Apr ’09 at 12:55pm

sorry, it should read ttf2eot

43. By Ralf Herrmann on 23rd Apr ’09 at 13:11pm

It does not work for me with IE browsers (Windows XP), any help will be appreciated!

You cannot simply link the EOT file on Jon’s server, because it is bound to one specific domain and won’t work on any other website. You need to create your own EOT file.

44. By Florent V. on 26th Apr ’09 at 17:39pm

Two technical notes:

First, as Paul said, there is an utility for Linux (but i was able to compile and use it on OS X with very little hassle: just had to use the <kbd>make</kbd> command in a terminal) that enables you to convert a TrueType file to Embedded OpenType. Way easier than WEFT, but you need TrueType, in my experience OpenType files won’t work.

Second: i wrote my own test page (in French), and found quite a few things in the process. The most notable one was that Internet Explorer 8 (and probably the previous versions as well) will load the TrueType/OpenType font file as well. The CSS styles specific to Internet Explorer will not override the normal styles, well to some extent they will but IE will still download both .ttf (or .otf) and .eot files. Seeing how a font file can be 50-150 KB, this is bound to hurt performance quite a bit!

One solution is to make sure you use the format("truetype/opentype") syntax, that will make IE fail to recognize that the URL ended and try to download a file called filename.ttf") format("truetype" for instance. Which will result in a 404 error: not perfect, but way better than downloading some unnecessary 50-150 (or more) KB.

45. By John Durdin on 30th Apr ’09 at 15:21pm

Great article, Jon… just found it. But one major issue with EOT fonts and WEFT that does not seem to be mentioned is when dealing with fonts for scripts not yet supported by Microsoft. Lao language uses a script that has only been (partly) supported by MS since Vista, so Lao users around the world have had to download fonts before being able to read websites. I have used WEFT, and have encouraged developers to use WEFT and embed one of my Lao OT fonts freely, but it was too difficult for most to handle. There are many scripts out there for which this would be true.

46. By Oli on 1st May ’09 at 00:22am

This font subsetting tool by Philip Taylor creates subset fonts and also generates .eot fonts. As long as you want to use one of the fonts listed (only fonts with a license that allows modification and distribution are included), you’re good to go. It includes the Japanese M+ (Mplus) font too!

47. By yann on 9th May ’09 at 09:30am

Just wondering, anyone tried this command line utility?

http://code.google.com/p/ttf2eot/

might be a good alternative to the MS application.

48. By Florent V. on 9th May ’09 at 10:43am

Yann: yes, see comments #41, #42 and #44 above.

49. By Yann on 9th May ’09 at 10:55am

oops… I read up to #30 or so… should have gone all the way I guess ;) My bad.

50. By burs on 10th May ’09 at 14:10pm

PostScript-flavoured OpenType fonts are not working in the Firefox beta in Windows (TrueType do work). It’s a known bug and will get fixed.

51. By meenah on 16th May ’09 at 06:28am

ttf2eot is also available for Windows. It’s as easy as ttf2eot squigglyfont.ttf squigglyfont.eot. They say you should preferably keep using WEFT but I don’t see why. ttf2eot just works. The resulting EOT file is comparable in size to the TTF. The WEFT idea of omitting characters that are not currently used is a failure because you can’t reuse the font, and it will break your website as soon as a string/database field changes. If Microsoft is serious about i18n they should just ditch it.

Btw is there a way to specify an alternative EOT font without conditional comments? I hate them.

52. By meenah on 16th May ’09 at 06:55am

Looking for a @font-face fallback for older browsers, I just found this script for sIFR:

http://shepherd-interactive.com/#about-us/blog/2008/06/cross-browser-web-fonts/#xbwf-sifr

[way to abuse a fragment identifier — url is truncated by the blog software, you have to copy&paste it]

Of course sIFR is Flash, so you might prefer some serverside PNG generator or Cufón or some other hack instead. It shouldn’t be too hard to adapt that script.

53. By Ralf Herrmann on 16th May ’09 at 07:41am

They say you should preferably keep using WEFT but I don’t see why.

The tool doesn’t allow to define URLs for URL-binding, which is probably the main reason for the existance of the EOT format. And it doesn’t use the Monotype compression engine, so the files will stay pretty large.

Btw is there a way to specify an alternative EOT font without conditional comments? I hate them.

Just define 2 fonts:

@font-face{ font-family:'MyFontEOT'; src: url('myfont.eot'); }

@font-face{ font-family:'MyFontTTF'; src: url('myfont.ttf') format('truetype'); }

h1 { font-family:MyFontEOT,MyFontTTF, Arial, Helvetica, sans-serf; }

54. By Ben on 7th Jul ’09 at 00:54am

serious / commercial sites would use licensed fonts. there would still be a lot of hobbysites without a license for the used fonts. but who cares? nothing would change for any font foundry, except they could earn more.

55. By karel zeman on 28th Aug ’09 at 22:01pm

When we imagine that we’ll be able to do with we quickly understand that it will become essential.

Secondly Does it work with XULRunner apps using chrome src URLs?

Thanks

56. By randsco on 31st Aug ’09 at 09:19am

Recent developments are making 2009 the year of fancy web fonts! With 30-Jun-2009 release of FireFox 3.5, it’s now possible for cross-browser font embedding, using the @font-face directive.

How to embed fonts w/CSS (a cross-browser solution)

Bottom Line: 97+% of our visitors get to see our fancy CSS-embedded fonts. The solution is better and easier than image replacement, sIFR, Cufon, FLIR or TypeKit. It’s valid CSS3 code, requires no hacks, isn’t dependent on JavaScript or Flash, doesn’t require a rental fee and doesn’t depend on 3rd-party servers. (And, you don’t even need conditional comments to satisfy the IEs). What’s not to love?

As an added bonus, I’ve also included links to several online font converters (TTF2EOT, OTF2TTF & DFONT2TTF) and also present an easy workflow for those that want to use WEFT.

Hope this helps!

57. By Paul Irish on 3rd Sep ’09 at 23:19pm

I’ve written up a summary of all the @font-face implementation syntax techniques, along with the best one I think there is… which hasn’t been covered yet!

Bulletproof @Font-Face implementation syntax

I’d invite everyone to give it a peek.

58. By stk on 4th Sep ’09 at 19:49pm

I can vouch for Paul Irish’s “Bulletproof syntax”.

I put it to the test. It’s valid, it works & it neatly side-steps a problem with IE, when using 2 @font-face selectors.

Great job, Paul!

59. By Lys Konuları on 5th Sep ’09 at 16:24pm

This is an interesting share. I will try but I have a question : Is there any bug in this? Because my sites have been under attack sometimes in the past. thanks

60. By Radyo on 13th Sep ’09 at 08:52am

Thanks for informative share. great job.

61. By DR on 16th Sep ’09 at 10:51am

@Lys Konuları

There is a cockroach. Beware, she will attack and will survive nuclear attacks.

62. By GZ on 17th Sep ’09 at 08:46am

Tnx for this, very usefull… the open source tool to convert .ttf to .eot can be find : HERE :-)

63. By Sebastian Green on 12th Oct ’09 at 13:54pm

Brilliant article. Its still definitely a hot topic.

64. By Jon 陳 on 13th Oct ’09 at 01:14am

Thanks for all the comments, folks. As you can see this article was written in October, 2008. In that time, there’s been fantastic progress around @font-face including an upcoming service I’m involved in, Fontdeck. In regard to linking fonts in IE, Paul Irish has a great article with superb comments that discusses the solutions even further. On that note, comments will be closing shortly; I’m glad this was useful in the early days, and thanks again for all of your responses and thoughts!

Lately in the Log

Anakin — Tue, 26th Jun 2012 {4}

I’m pleased to be able to say that Analog is joining forces with…

We, Who Are Web Designers — Mon, 19th Sep 2011 {66}

In 2003, my wife Lowri and I went to a christening party. We were friends…

Ampersand, the Aftermath — Wed, 22nd Jun 2011 {3}

The first Ampersand web typography conference took place in Brighton last…

Design Festival, The Setup, and Upcoming Posts — Mon, 20th Jun 2011 {0}

Wow, this has been a busy period. I’m just back from the Ampersand…

Web Design as Narrative Architecture — Wed, 30th Mar 2011 {12}

Stories are everywhere. When they don’t exist we make up the…

Ides of March — Tue, 15th Mar 2011 {4}

My friend and colleague, Chris, has shared a spiffing idea, the Ideas of…

Remarks from the log

By pixelangry in We, Who Are Web Designers:

Unfortunately, here in Italy, the figure of the web designer is seen as a figure who plays a nerd on the computer,…

By George in Copywriting, Experience Design, Daleks & Julio:

Thanks

By Martins in Typeface != Font:

Great post Jon, I stumbled across it by chance on Google..!!

By DarkStar in Smoothing out the Creases in Web Fonts:

I agree with Leicester that table is great!

By Martin Varesio in Ampersand, the Aftermath:

His dry, droll, richly-flavoured delivery was a humorous counterpoint to some controversial asides…

By Steve Blakeborough in Display Type & the Raster Wars:

Hi Jon, In Elliot’s recent and informative article http://bit.ly/13sAS5X he suggested you might be bullied…

Footnotes

This simple dish was created with a little xHTML, a dash of CSS and a pinch of PHP. It’s garnished with hAtom, hCalendar, XFN, hCard and rel-tag with a large slice of accessible intent. Hopefully it plays nicely, all the time.

1. By johno on 31st Oct ’08 at 10:58am

There’s a lot of work behind this article. Great job, Jon. The missing cap A bar is a strange one. I’m looking into that. Well, you’ve certainly made the whole more comprehensible. Thank you.
2. By Peter Gasston on 31st Oct ’08 at 10:58am

Stupendously in-depth article, Jon; congratulations. As for your closing summary, I agree with you completely.

IMHO, font vendors should learn the lesson of the music and film industries and look not to fight the web, but for ways to embrace and profit from it .
3. By Leon Paternoster on 1st Nov ’08 at 01:32am

You might pay, Jon, as will anyone working commercially, but think of the millions of websites that won’t. Of course, there’s nothing to stop people downloading illegal copies of fonts at the moment, but this will just make it more desirable, and easier, to do so.

Still, this looks like it’s going ahead in some form or other. I must admit that I’ll miss working with such a small set of fonts: I feel it’s really focused my web typography. I guess we’ll see some pretty horrendous/illegible combinations.

Sorry to be a typo PITA again, but who’s is wrong in the first line of your summary.
4. By Ray on 1st Nov ’08 at 02:29am

The subject of web fonts is dear to my heart. Web fonts/@font-face/font embedding/whatever you wish to call it is a promising technology—and has been, as you write—for over a decade. You clearly understand a good deal of the history of the subject but saying “please respect the EULAs… until the type community resolves the issue for all commercial fonts” seems to ignore this history of font embedding; or at the very least, the length of this history. To characterise the movement of all the actors involved as “sluggish” is an insult to slugs.

I’m not suggesting that designers pursue illegal activities with the usage of fonts. But a “wait and see” approach will only contribute to the general lethargy of the actors. The only real reason why there’s been any real movement on the use of @font-face (I feel) is because of the Acid3 test, which requires the use of @font-face. If the Acid tests have done anything, it’s been to spur developers into swifter, more mutually-beneficial action & is therefore praiseworthy.

As for the missing “A” bar in WEFT-created EOT files (and for using WEFT in general), I sympathise with you. I had very similar problems (cited in the article above) & it seems to be an issue with the font itself, not necessarily with WEFT.
5. By Jon B on 1st Nov ’08 at 04:16am

Firstly, thanks for some further insight into this (especially WEFT which I’ve tried to use several times and always ended up scratching my head and wondering why it isn’t just a hell of a lot easier – afterall, all an EOT needs is a font file, a domain, and the characters you want to include in it – why did MS make that so hard!)

Like others I share concerns of 'stealing' fonts, not that I make any myself, or am in a position to pay large fees for using them – but there is a lot of 'stolen' work on websites which never even gets attributed (icons, images, text, and soon fonts it seems) However I am not so taken with EOT, purely because of the complicated time consuming process (and lack of support obviously). There has been suggestions by various people of creating centralised 'font pools’ for web fonts, and that this could be the future of font foundarys, which as I understand for now firefox 3.1 would be the only browser to support (I think, as it can do HTTP license checking?) To me this would be a great solution, fonts are managed by account, you pay to add domains to them – and they are served by fast servers (I’m not entirely sure how fonts are cached, but this could be a bonus too) This method could also work with EOT, with the foundary automatically creating appropriate EOT files and serving them in the same way. Safari can loads fonts from any domain and doesn’t check licenses – but potentially with a bit of referer checking this could be handled too I’d imagine (until they get up to speed) So my thoughts are that font makers should look to this as a good thing and work on ways to monetize it quickly before they miss out.
6. By Jon 陳 on 1st Nov ’08 at 06:35am

Thanks for all of your contributions, it’s great to get these kinds of quality insights from colleagues. Something I want to add here is that I think there are three other critial elements to improving web typography:

1. A grass roots, standards-driven movement to identify and curate an enhanced set of core web fonts. They would include much better type style variants. They would be paid for by a mixture of sponsorship, public funds and grass roots donations allowing an organisation to commission type designers at commercial rates. Lastly, and critically, they would be delivered freely with operating systems under agreement with the companies involved. N.B. Internationalisation is imperative in any future development of enhanced core web fonts. Universally available, platform-independent, high-quality system fonts would be the goal.

2. CSS to develop in line with OpenType tags to enable control of advanced typographic features in user agents like ligatures.

3. Rendering engines to do a better job of rendering fonts supporting the full range of subtlety that can make or break typography on the screen such as hinting, anti-alias, kerning, ligatures, hyphenation, etc.
7. By westworld on 3rd Nov ’08 at 05:02am

Maybe font companies could host a web version of the font’s that they are selling.

Stuff like a full open type version, a version stripped of non English characters, a bold and an italic version. People could then link to these and only get access if they payed (you could do this based on serverip for example).

Popular fonts could even be in the visitors browser cache

This helps web designers who don’t have a clue about fonts. Imagine sending a full Vandekeere to you visitors while the page only uses 20 glyphs. Just because you dont have a clue how to remove unused ones.

Letting someone else host the font is also good for speedy download. If my memory serves me, browsers only take two simultaneous downloads from one domain.

just my 2 cents
8. By Jens Meiert on 4th Nov ’08 at 03:43am

Nice round-up, however I may note that Conditional Comments still have a negative impact on maintainability (even amplified by using style elements instead of external style sheets, as in the example), and thus caution yet patience seem to be quite recommendable I fear.
9. By ST on 4th Nov ’08 at 10:10am

Your example: (link – converted to proper hyperlink by Ed.)

In firefox looks like its defaulting to georgia?? Not working in firefox, seems to work in Safari though~
10. By Jon 陳 on 4th Nov ’08 at 12:02pm

ST, it works in 3.1 beta as the article mentions. I assume you were using an older version? Please re-read carefully and, if you find a problem, please be specific with the browser version number to help debugging. Many thanks.
11. By ST on 4th Nov ’08 at 17:55pm

Ah, my mistake!! Thanks for clearing that up, my version of Firefox was 3.0 X-p

Great article by the way, it had me experimenting all morning! Thank you Jon!
12. By Robbie on 9th Nov ’08 at 21:06pm

I’m not seeing Fontin with Firefox 3.1b1.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1

It is working in IE 7 on the same machine.
13. By Jon 陳 on 10th Nov ’08 at 01:15am

Hi Robbie, it seems to working fine with 3.1b on OS X. Has anyone else tested using 3.1b in the context Robbie has posted?
14. By Jon Gibbins on 10th Nov ’08 at 02:36am

If anyone is interested on trying WEFT on a Mac, when running on Windows XP using VMware, WEFT doesn’t seem to pick up on installed fonts. Parallels does appear to work. Just remember that WEFT will not pick up on OpenType font files installed in your system Fonts directory, only TrueType font files.
15. By Robbie on 10th Nov ’08 at 10:38am

@Jon I did a quick test on OS X with FF 3.1b1 and the test page worked fine. Must be isolated to the Windows version.
16. By Ralf Herrmann on 11th Nov ’08 at 13:51pm

PostScript-flavoured OpenType fonts are not working in the Firefox beta in Windows (TrueType do work). It’s a known bug and will get fixed.
17. By Charles Cooper on 13th Nov ’08 at 07:17am

This seems like it sould be easy to do, and I thought I’d give it a try, but it doesn’t seem to work. Anyone able to suggest where I’ve gone wrong?

I can view all samples posted at the referenced link (A List Apart), so based on a quick reading, I thought this stripped down pagelet should work.

Any suggestions, anyone?

I’m viewing it on XPpro, SP2, using IE6 (yes, I know), FF2.X, NS9, Opera 9.61 and Safari 3.1.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" > <head> <style> h1{ font-family: "Fontin-Regular"; } @font-face{ font-family: "Fontin-Regular"; src: url("http://www.rockley.com/chamber/fonts/Fontin-Regular.ttf") format("truetype"); } </style> </head> <body> <h1>this is Header1</h1> This is Paragraph text </body> </html>

It’s probably something embarrassingly obvious – and I’m willing to be embarrassed if it helps me learn!
18. By Jon 陳 on 14th Nov ’08 at 02:28am

Hi Charles. Which browsers specifically does it not work in? Is it all browsers? Your example worked fine for me with a quick test in Safari 3.1.2 / OS X.

I’ve cleaned up you comment and removed multiple line breaks from the example. As you’ve probably guessed, my home-rolled app is not built to handle multiple lines of code in comments (hence the lack of a pre tag in the style guide). You may wish to consider putting examples on your own domain and linking to them. Cheers!
19. By Ralf Herrmann on 14th Nov ’08 at 03:26am

I’m viewing it on XPpro, SP2, using IE6 (yes, I know), FF2.X, NS9, Opera 9.61 and Safari 3.1.

Look here:

http://www.webfonts.info/wiki/index.php?title=%40font-face_browser_support

Of all the browsers you mentioned only Safari 3.1 currently supports direct linking of TTF/OTF fonts. It also won’t work in the upcoming Firefox 3.1, since you used an absolute URL to the font file.
20. By John on 14th Nov ’08 at 11:56am

OTF-Support for Firefox 3.1ß1 under Windows is broken for the moment.

Windows: Postscript-style OTF fonts (i.e. CFF fonts) don’t load [bugzilla]
21. By Charles Cooper on 14th Nov ’08 at 12:53pm

Jon – thanks for cleaning up the code. I appreciate it. I’ll link future code snippets to my own domain as requested.

It doesn’t work with any of the browsers mentioned in the initial post.

Ralph – thanks for the link to the supported browsers. Appreciate it.

John – thanks for the link.

Too bad. It looked like an easy way to support simple font changing for titles and such.

Presumably if I used parallel declarations for Safari 3 and FF (.otf) and IE4/7 (.eot) it would work, but not with TT in the foreseeable future due to the number of people using old browsers.

Is that a reasonable assumption?

coop
22. By Ralf Herrmann on 15th Nov ’08 at 00:08am

Presumably if I used parallel declarations for Safari 3 and FF (.otf) and IE4/7 (.eot) it would work, but not with TT in the foreseeable future due to the number of people using old browsers.

Sure it works with TT. Safari, Firefox 3.1 and a future version of Opera will all support TrueType, OpenType TT and OpenType PS fonts.

It you put an addition EOT font in your @font-face declaration you will also support IE users since version 4.0!

(By the way: EOT is nothing than a TrueType/OpenType font within a wrapper)
23. By Charles Cooper on 15th Nov ’08 at 19:12pm

Thanks very much – I’ll give that a try and see how it works.
24. By Patrick Algrim on 18th Nov ’08 at 12:44pm

Awesome write-up. I am really glad to see that people are focusing on the font issues. Typography is such a huge importance when it comes to Web design. I would love to get rid of images all together. Personally, I am not a huge fan of it. I really like sIFR, but I have notice some huge performance issues that can go along with it. Personally, I think this type of embedding won’t take presidency for a little while. It’s still extremely common to be worried about IE 6 and up. It’ll be tricky to get around everything, but it looks like this is such an amazing start! Great job to everyone!
25. By Ben Clarke on 27th Nov ’08 at 08:11am

My favourite bit on the Microsoft typography page you link to:

This technology is changing the look of the Web, by empowering site designers to ensure their pages appear as they want them to. Check out the following examples.

…

this page was last updated 26 February 2001.
26. By Jon Gibbins on 4th Dec ’08 at 05:52am

And so, Opera 10 alpha adds Web Fonts support. So, with Opera and Firefox support on the way, it looks like we should see some action in this area in the not-too-distant future.
27. By Alex on 21st Dec ’08 at 21:34pm

"…If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long."

That happened a long time ago, EOT as it stands offers barely any protection over normal OTF or TTF fonts (It’s up to the browser to respect the domain restrictions, but for browsers to show the font, they have to turn the file into a normal OTF or TTF file and dump it on the file system anyway) Even IE was hacked to dump out the raw OTF/TTF files when it encountered a EOT file.

Basically, you can throw all the DRM you want at this problem, but by the nature of how it works, it can’t be solved in a way that will suit all parties. And I’ll lean towards a solution that annoys some people but makes it easier for everybody, rather than a solution which makes some people happy, but annoys everybody else and makes it harder to use font embedding for no reason.
28. By Jon 陳 on 22nd Dec ’08 at 01:39am

Thanks for he useful additions, Ralf. I appreciate all the work you’re doing in this area. Great to see Opera about to round out the support as per Jon’s comment.

Alex, thanks for your technical insight. Have you any references or links? I agree with you regarding preferred solutions — it’s some of the foundries and type designers who we need to bring with us, I think.
29. By Christopher Olberding` on 22nd Dec ’08 at 14:22pm

Very good and comprehensive article. I admit that I haven’t kept up to developments in this area very closely as it has long seemed that there were too many barriers for opening things up.

Doesn’t really seem like there has been enough progress for me to start getting my hands dirty but I will be keeping a closer watch.
30. By Alex on 23rd Dec ’08 at 14:42pm

Reverse Engineering the Embedded OpenType Decompression

That article is about hooking the core EOT library to get it dumping the EOT data to TTF files, but you don’t need to use that method to get the font info. A EOT font is a normal OpenType font with some extra data, the font data can be compressed or “encrypted” (It’s in quotes since it isn’t really encryption), and the EOT header will say which it is, so any app that loads EOT files without using the MS API (e.g. any web browser not on Windows) will need to decode the font and convert it into an unprotected format, what it does from there can differ (Firefox used to dump all the files to disk, monitor the right folder and you’d see the .ttf files appear during page load, might have changed though).

That you can turn a TTF file into an EOT file, then turn that EOT file directly back into a TTF file seems to make the whole system pointless. It won’t stop anybody actually using the font, but it would stop somebody just downloading the EOT file and trying to use it, which is what they actually want I suppose. But it seems like a whole lot of effort and trouble for little to no protection. I suppose one “argument” for EOT is that there aren’t many tools to do the conversion, but I think that’s just a sign that nobody really cares about the format.

Also, try getting these tools to play nicely with PostScript outline OpenType fonts, WEFT won’t convert it, MS’s EOT API won’t load it, and Uniscribe won’t shape it.
31. By justpassingby on 9th Jan ’09 at 23:57pm

You can download SWF files (and there are commercial decompilers)… Has this stopped the Flash Developer Community from uploading tons of games and stuff?

You would expect that MP3 files are secure on the myspace page of an artist (or their Official Website)… nope… Has this kept them from posting new music?

Difficult age we live in, definitively…
32. By sbs on 3rd Feb ’09 at 13:22pm

what a impressive article. last days I didn' t read post like that. I am now your blog' s follower thanks for this useful blog. you are now in my bookmarks.
33. By Joe Pea on 7th Feb ’09 at 22:53pm

I have firefox 3.1 beta 2 and the font does not appear in the browser on the example page. ???????? Do I have to do something? I would really like for this to work!! This should be standard in web design. I mean if all browsers can handle something as complex as Flash, shouldn’t something so simple as fonts be universally applicable as well? People have overlooked this. Having any site’s custom font should be as easy to display as is Flash (If not, easier).
34. By josh on 24th Feb ’09 at 07:29am

This is a great article, I really appreciate that you covered just about every aspect of making web fonts work on the web in, including the politics. I had no idea that web fonts had actually progressed this far. Even though there are a few problems as you mention, it seems like embedding fonts could become a not too far off technique for web designers.
35. By Alex on 25th Feb ’09 at 18:57pm

@ Joe Pea

Are you on Windows? Because there’s a bug in Windows that means OpenType PostScript fonts (like the Fontin font used on the test page) don’t work, it’s been worked around in Firefox though (as in, works for English text, maybe not other languages) so Beta 3 (when it’s released) should show them fine. Hopefully the core bug will be fixed in Windows 7, but unfortunately that won’t fix the bad anti-aliasing MS applies.

And browsers don’t handle Flash at all, they load the plugin and it renders itself, and personally I view a few lines of CSS as easier than going the whole Flash route (although trying to work out the platform specific font matching rules is a bit strange, especially when they vary on the same platform depending on the font type)
36. By Joe Pea on 26th Feb ’09 at 09:57am

Yeah I tried in in Firefox 3.1 beta 2 and Google Chrome and Firefox 3.0 but the font isn’t visible in any of the browsers. Are there certain settings to adjust maybe?
37. By Webtiful on 1st Mar ’09 at 17:53pm

Great article. I will try it. Thanks
38. By sivas on 9th Mar ’09 at 13:41pm

very good. thank you.
39. By killsifr on 19th Apr ’09 at 04:58am

The example doesn’t work in my Opera 10 alpha. It works in IE7, IE8, Firefox 3.1b3, Safari 4 beta and Chrome 2, all on Windows XP.
40. By yucc on 20th Apr ’09 at 00:05am

It does not work for me with IE browsers (Windows XP), any help will be appreciated!

<blockquote>

<html xmlns="http://www.w3.org/1999/xhtml” xml:lang="en” >

<head>

<style>

h1{font-family: “Fontin-Regular";}

@font-face{font-family: “Fontin-Regular";

src: url("http://jontangerine.com/silo/typography/font-face/Fontin-Regular.eot");}

</style>

</head>

<body>

<h1>this is Header1</h1>

This is Paragraph text

</body>

</html>

</blockquote>
41. By paul on 23rd Apr ’09 at 12:54pm

if you are on linux, you can use ttf2oet script to easily convert a TTF to EOT !!
42. By paul on 23rd Apr ’09 at 12:55pm

sorry, it should read ttf2eot
43. By Ralf Herrmann on 23rd Apr ’09 at 13:11pm

It does not work for me with IE browsers (Windows XP), any help will be appreciated!

You cannot simply link the EOT file on Jon’s server, because it is bound to one specific domain and won’t work on any other website. You need to create your own EOT file.
44. By Florent V. on 26th Apr ’09 at 17:39pm

Two technical notes:

First, as Paul said, there is an utility for Linux (but i was able to compile and use it on OS X with very little hassle: just had to use the <kbd>make</kbd> command in a terminal) that enables you to convert a TrueType file to Embedded OpenType. Way easier than WEFT, but you need TrueType, in my experience OpenType files won’t work.

Second: i wrote my own test page (in French), and found quite a few things in the process. The most notable one was that Internet Explorer 8 (and probably the previous versions as well) will load the TrueType/OpenType font file as well. The CSS styles specific to Internet Explorer will not override the normal styles, well to some extent they will but IE will still download both .ttf (or .otf) and .eot files. Seeing how a font file can be 50-150 KB, this is bound to hurt performance quite a bit!

One solution is to make sure you use the format("truetype/opentype") syntax, that will make IE fail to recognize that the URL ended and try to download a file called filename.ttf") format("truetype" for instance. Which will result in a 404 error: not perfect, but way better than downloading some unnecessary 50-150 (or more) KB.
45. By John Durdin on 30th Apr ’09 at 15:21pm

Great article, Jon… just found it. But one major issue with EOT fonts and WEFT that does not seem to be mentioned is when dealing with fonts for scripts not yet supported by Microsoft. Lao language uses a script that has only been (partly) supported by MS since Vista, so Lao users around the world have had to download fonts before being able to read websites. I have used WEFT, and have encouraged developers to use WEFT and embed one of my Lao OT fonts freely, but it was too difficult for most to handle. There are many scripts out there for which this would be true.
46. By Oli on 1st May ’09 at 00:22am

This font subsetting tool by Philip Taylor creates subset fonts and also generates .eot fonts. As long as you want to use one of the fonts listed (only fonts with a license that allows modification and distribution are included), you’re good to go. It includes the Japanese M+ (Mplus) font too!
47. By yann on 9th May ’09 at 09:30am

Just wondering, anyone tried this command line utility?

http://code.google.com/p/ttf2eot/

might be a good alternative to the MS application.
48. By Florent V. on 9th May ’09 at 10:43am

Yann: yes, see comments #41, #42 and #44 above.
49. By Yann on 9th May ’09 at 10:55am

oops… I read up to #30 or so… should have gone all the way I guess ;) My bad.
50. By burs on 10th May ’09 at 14:10pm

PostScript-flavoured OpenType fonts are not working in the Firefox beta in Windows (TrueType do work). It’s a known bug and will get fixed.
51. By meenah on 16th May ’09 at 06:28am

ttf2eot is also available for Windows. It’s as easy as ttf2eot squigglyfont.ttf squigglyfont.eot. They say you should preferably keep using WEFT but I don’t see why. ttf2eot just works. The resulting EOT file is comparable in size to the TTF. The WEFT idea of omitting characters that are not currently used is a failure because you can’t reuse the font, and it will break your website as soon as a string/database field changes. If Microsoft is serious about i18n they should just ditch it.

Btw is there a way to specify an alternative EOT font without conditional comments? I hate them.
52. By meenah on 16th May ’09 at 06:55am

Looking for a @font-face fallback for older browsers, I just found this script for sIFR:

http://shepherd-interactive.com/#about-us/blog/2008/06/cross-browser-web-fonts/#xbwf-sifr

[way to abuse a fragment identifier — url is truncated by the blog software, you have to copy&paste it]

Of course sIFR is Flash, so you might prefer some serverside PNG generator or Cufón or some other hack instead. It shouldn’t be too hard to adapt that script.
53. By Ralf Herrmann on 16th May ’09 at 07:41am

They say you should preferably keep using WEFT but I don’t see why.

The tool doesn’t allow to define URLs for URL-binding, which is probably the main reason for the existance of the EOT format. And it doesn’t use the Monotype compression engine, so the files will stay pretty large.

Btw is there a way to specify an alternative EOT font without conditional comments? I hate them.

Just define 2 fonts:

@font-face{ font-family:'MyFontEOT'; src: url('myfont.eot'); }

@font-face{ font-family:'MyFontTTF'; src: url('myfont.ttf') format('truetype'); }

h1 { font-family:MyFontEOT,MyFontTTF, Arial, Helvetica, sans-serf; }
54. By Ben on 7th Jul ’09 at 00:54am

serious / commercial sites would use licensed fonts. there would still be a lot of hobbysites without a license for the used fonts. but who cares? nothing would change for any font foundry, except they could earn more.
55. By karel zeman on 28th Aug ’09 at 22:01pm

When we imagine that we’ll be able to do with we quickly understand that it will become essential.

Secondly Does it work with XULRunner apps using chrome src URLs?

Thanks
56. By randsco on 31st Aug ’09 at 09:19am

Recent developments are making 2009 the year of fancy web fonts! With 30-Jun-2009 release of FireFox 3.5, it’s now possible for cross-browser font embedding, using the @font-face directive.

How to embed fonts w/CSS (a cross-browser solution)

Bottom Line: 97+% of our visitors get to see our fancy CSS-embedded fonts. The solution is better and easier than image replacement, sIFR, Cufon, FLIR or TypeKit. It’s valid CSS3 code, requires no hacks, isn’t dependent on JavaScript or Flash, doesn’t require a rental fee and doesn’t depend on 3rd-party servers. (And, you don’t even need conditional comments to satisfy the IEs). What’s not to love?

As an added bonus, I’ve also included links to several online font converters (TTF2EOT, OTF2TTF & DFONT2TTF) and also present an easy workflow for those that want to use WEFT.

Hope this helps!
57. By Paul Irish on 3rd Sep ’09 at 23:19pm

I’ve written up a summary of all the @font-face implementation syntax techniques, along with the best one I think there is… which hasn’t been covered yet!

Bulletproof @Font-Face implementation syntax

I’d invite everyone to give it a peek.
58. By stk on 4th Sep ’09 at 19:49pm

I can vouch for Paul Irish’s “Bulletproof syntax”.

I put it to the test. It’s valid, it works & it neatly side-steps a problem with IE, when using 2 @font-face selectors.

Great job, Paul!
59. By Lys Konuları on 5th Sep ’09 at 16:24pm

This is an interesting share. I will try but I have a question : Is there any bug in this? Because my sites have been under attack sometimes in the past. thanks
60. By Radyo on 13th Sep ’09 at 08:52am

Thanks for informative share. great job.
61. By DR on 16th Sep ’09 at 10:51am

@Lys Konuları

There is a cockroach. Beware, she will attack and will survive nuclear attacks.
62. By GZ on 17th Sep ’09 at 08:46am

Tnx for this, very usefull… the open source tool to convert .ttf to .eot can be find : HERE :-)
63. By Sebastian Green on 12th Oct ’09 at 13:54pm

Brilliant article. Its still definitely a hot topic.
64. By Jon 陳 on 13th Oct ’09 at 01:14am

Thanks for all the comments, folks. As you can see this article was written in October, 2008. In that time, there’s been fantastic progress around @font-face including an upcoming service I’m involved in, Fontdeck. In regard to linking fonts in IE, Paul Irish has a great article with superb comments that discusses the solutions even further. On that note, comments will be closing shortly; I’m glad this was useful in the early days, and thanks again for all of your responses and thoughts!

By pixelangry in We, Who Are Web Designers:

Unfortunately, here in Italy, the figure of the web designer is seen as a figure who plays a nerd on the computer,…
By George in Copywriting, Experience Design, Daleks & Julio:

Thanks
By Martins in Typeface != Font:

Great post Jon, I stumbled across it by chance on Google..!!
By DarkStar in Smoothing out the Creases in Web Fonts:

I agree with Leicester that table is great!
By Martin Varesio in Ampersand, the Aftermath:

His dry, droll, richly-flavoured delivery was a humorous counterpoint to some controversial asides…
By Steve Blakeborough in Display Type & the Raster Wars:

Hi Jon, In Elliot’s recent and informative article http://bit.ly/13sAS5X he suggested you might be bullied…