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

30 Comments

1. By johno on 31st Oct ’08 at 17:58pm

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 17:58pm

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 08: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 09: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 11: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 13:35pm

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 13:02pm

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 11: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 18:10pm

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 20: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 5th Nov ’08 at 01:55am

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 10th Nov ’08 at 05:06am

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 09: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 10: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 18:38pm

@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 21: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 15:17pm

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 10: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 11: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 19:56pm

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 20: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 08: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 16th Nov ’08 at 03:12am

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

24. By Patrick Algrim on 18th Nov ’08 at 20: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 16:11pm

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 13:52pm

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 22nd Dec ’08 at 05:34am

"…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 09: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 22: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 22: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.

Growing OmniTI — Sun, 21st Dec 2008 {21}

’Twas the week before Christmas, and all was hectic in the…

PHP Advent Seasoning — Tue, 16th Dec 2008 {5}

Ladies and gentlefolk, I give you the two-thousand and eight PHP Advent…

Display Type & the Raster Wars — Thu, 6th Nov 2008 {21}

ClearType is 10 years old this Autumn. For most of that time it lay hidden…

Happy Birthday, Son! — Wed, 5th Nov 2008

Dear Xen, you’re five today. Five years old! You left for school this…

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 17:58pm

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 17:58pm

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 08: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 09: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 11: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 13:35pm

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 13:02pm

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 11: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 18:10pm

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 20: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 5th Nov ’08 at 01:55am

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 10th Nov ’08 at 05:06am

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 09: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 10: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 18:38pm

@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 21: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 15:17pm

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 10: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 11: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 19:56pm

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 20: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 08: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 16th Nov ’08 at 03:12am

Thanks very much – I’ll give that a try and see how it works.
24. By Patrick Algrim on 18th Nov ’08 at 20: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 16:11pm

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 13:52pm

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 22nd Dec ’08 at 05:34am

"…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 09: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 22: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 22: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.

Remarks from the log

By Leicester in The Incredible Em & Elastic Layouts with CSS:

Really well written and explained article, had always wondered what the uses of ems were.
By flashoyun in The Incredible Em & Elastic Layouts with CSS:

thanks for nice stuff
By oyunlar in The Incredible Em & Elastic Layouts with CSS:

It really inspired me to build elastic layout. thanks.
By Leicester in Smoothing out the Creases in Web Fonts:

Hey I found that table extremely useful, thanks for sharing it.
By Jawad Farooq in The Incredible Em & Elastic Layouts with CSS:

Thanks, Very easy and and complete explanation Great, much appreciate