Font Embedding on the Web

Hi! It’s Bill Hill here again, still fighting the good fight to make typography on the Web as good as we’re used to seeing in print. We made significant progress this week, when one of the USA’s most prestigious font companies announced its support for the Embedded OpenType format for font embedding on the Web, and launched a new website to promote other browsers to support it in addition to Internet Explorer (which has had EOT support built-in since 1996).

At the same time, Ascender Corporation and its collaborators in the typographic community also warned of the legal dangers of using the Font Linking mechanism currently supported by other browsers.

Read the announcement in full or visit the new Ascender site for further details.

Font Embedding with EOT

Embedded OpenType (EOT) is currently before the W3C in a submission to make it an open Web Standard. The format was previously proprietary to Microsoft. We created it to enable font embedding within Microsoft Word documents in the early 1990s, and it was later extended for use on the Web by Internet Explorer.

In its introduction to the technologies of font embedding on the Web, Ascender says, ”Fonts play a critical role in the display, printing and manipulation of text-based information and content. Font embedding is a broad and complex topic, and we hope this website becomes a valuable resource for everyone who creates or uses fonts to learn more about proper font usage and licensing.”

The website has sections covering issues such as:

  • Fonts and the Law
  • Document Font Embedding
  • Fonts and the Web (a comparison of the various embedding technologies)
  • Shipping Fonts with Applications, Digital Content, and Devices

In the section on Fonts and the Web, Ascender compares EOT, sIFR and Font Linking, and welcomes the move by Microsoft and Monotype Imaging to propose EOT as a W3C standard (Monotype Imaging, another prestige font company, developed MicroType® Express compression to reduce the size of EOT files). The proposal has been with W3C for several months.

“EOT offers several advantages for type designers, and web designers. For type designers EOT creation tools must respect the embedding permissions built-into their fonts and EOTs are bound to a specific web page or site. For web designers an EOT can contain a subset of the glyphs, and it can be compressed – both of these features can shrink EOT file sizes to reduce download times and improve performance,” says Ascender.

Font Linking, in which raw font files are stored on a server and downloaded using the @font-face mechanism, falls outside the realm of fonts embedded in documents, Ascender warns. ”Web page designers should be very careful to avoid violating commercial font EULAs (end-user licensing agreements) by placing fonts on Web servers”. Ascender’s own EULA, for instance, prohibits installing fonts on servers without purchasing an extended license.

In concluding its comparison, the website continues, “Ascender believes that although not perfect, EOT represents the best current solution for type designers and font foundries to protect their Intellectual Property. It is the only web font embedding solution that respects font embedding permissions, uses an industry-proven subsetting and compression mechanism, and ties embedded fonts to specific web sites. Ascender hopes that other web browsers will make it a priority to support EOT once it becomes a W3C standard.”

The site also has some free fonts to promote the technology, and the first Web-based EOT creation tool.

This endorsement prompted me to go back and start playing around with font embedding, since I hadn’t looked at it in some time. I started by downloading WEFT, the Windows Embedding Font Tool, from the Microsoft website.

Before you try to use the tool in earnest, it’s really worthwhile going through the tutorial on the same page, which has some code samples. There’s also more good information in the “Troubleshooting and Testing” section on the WEFT page.

Don’t expect the tool to do all the work, though. It’s great at creating EOT files and the CSS Font Declarations used to link your pages to them. But - depending on the complexity of the source files for your pages - you may have to do some manual coding to get them to work properly.

Give it a Try, with a Caveat 

Here, I have to do a huge mea culpa.

Creating a set of pages using EOT allowed me to experiment with what a blog, for instance, might look like if it was designed for readability. But I’m a type and font guy – not a Web code jockey. I just wanted to see, quickly, what readable pages might look like. This was an experiment. I didn’t want to start hand-crafting pages. So I took the easy route, and used a publishing application with which I’m very familiar to generate the multicolumn pages.

This is “throwaway code”. It’s verbose, arcane and in lots of places it’s proprietary. A real Web guru like Chris Wilson takes one look, and you just know he’s controlling the urge to scream. The W3C HTML Validator, though, doesn’t manage to control the urge to scream: “85 coding errors, you moron! Starting with no <Doc Type>!

My pages offended Chris so much, he immediately made a start at re-coding them so they’ll validate and meet Web standards. If I was a sensitive soul I’d be offended, but like I said, I’m no coder. And what a great way to recruit a very busy guy to do some coding for you. My pages are like a crooked picture on a wall which Chris passes every day – if he doesn’t straighten it, it’ll drive him mad…

Just his first pass at making a “legitimate” version of the first page took its size down to only 25% of the original. And even I can tell the code’s a lot better. We’ll work to get “legitimate versions” of the pages posted. We’d have preferred to do this before this blog post, but Chris said something about wanting to spend the weekend with his family or something :), and I wanted to highlight the Ascender announcement while it was timely."

Anyway, if you’re going to blame anyone for the code, blame me.

With that huge caveat, you’ll find my pages at:

They’re definitely a work in progress, so expect the odd glitch. For example, one or two people have reported mild clipping issues on some displays. I’ll need to investigate.

They were designed to be viewed on a 1400 x 900 display, and should be viewed using the F11 key to make Internet Explorer go FullScreen, to get rid of menus, address bars and anything else that distracts from reading. I’ve got into the habit of toggling F11 to go from my personal “reading” mode to “browsing” mode – where I want all those menus and toolbars…

I had to manually tidy up and paste the @font-family declarations, which look like this:

   @font-face {
   font-family: Cambria;
   font-style: normal;
   font-weight: normal;
   src: url(CAMBRIA2.eot);

I’ve given feedback on these issues to the team, and we’re working out what can be done to reduce the need for manual tweaking.

Of course, since we’ve opened up the EOT format, we hope other tools will soon be generating EOTs as well, such as the Ascender site. Since the W3C submission includes sample code, it would be great if the tools you use to author pages would integrate EOT generation into the process. Then the code would be more tightly integrated as well.

The good news is that if you have to do some manual tweaking, once you’ve got it right for one page, the code can be easily copied and pasted into your other pages. Even better, you can put it in a Style Sheet, and have all the pages reference it.

Working with WEFT and EOT

One performance tip for embedding fonts in your pages is to use the subsetting capability available in the WEFT tool to generate the font objects with only the characters you need. They’ll be smaller, and faster to download.

For instance, if you write in English, then you’re unlikely to use the Cyrillic or Greek characters, and you could use “language-based” subsetting. There are seven subsetting options in the tool, including “per page” and “per site”. Since my test site’s a blog which should be frequently updated, I opted at first for “no subsetting”, which creates the largest font objects - but means I’ll never need to update them whatever new content I create in future.

However, on reflection, I thought this might be overkill, and tried language-based subsetting, and got a huge performance improvement!

Calibri and Cambria, for instance, are big fonts with four true weights each, all of them painstakingly hinted for maximum readability at small sizes. The four weights ended up as font objects of ~175K each without subsetting. With language-based subsetting, they were only one-third the size of the original EOTs and the page rendered just the same – only a lot faster.

Nice thing is, as long as I made sure the names of the objects for each font and style remained the same, I was able to just swap out the objects in the root directory of my site, without having to change the code in any of my pages.

Another production tip from my experience which can save you a lot of time: WEFT will let you analyze pages on your Web server – but you can tell it to create the font objects on your local hard drive. Generating the objects on the Web can take a loooong time. Using your local machine it’s very quick, and you can then FTP them to your site.

Font embedding is critical not just to allow designers to make distinctive pages, but for readability. Building fonts that work for text at normal reading sizes of 11 and 12 points requires a lot of work. It could take a designer anywhere from a year to three or more years to develop a full character set, hint it properly to work at screen resolution, and so on.

However, anyone who has a copy of Windows Vista, Office 2007 or Mac Office 2008 already has a great set of fonts they can embed in Web pages. They’re called the C* fonts (because they were optimized for ClearType, and thus all given names which began with “C” J): Calibri, Candara, Consolas (a monospaced font for coding), Cambria (which also contains a set of 4000 Math characters), Constantia and Corbel.

I know personally how much effort went into creating them, because at the time I was managing the group which ran the project. Outside designers created the outlines from their winning entries for a competition we ran, and then the fonts were hinted by the best in the business.

The project took a long time and cost a lot of money – which is why we don’t just give these fonts away. They add a lot of value to the applications (and operating systems) which ship them. But they all have Embedding permissions set to “Editable”, which means you can freely embed them using EOT, as long as you bought one of the products in which they shipped – although you are not allowed to just copy the .TTF font files to a server.

My absolute favorites for reading on screen are Cambria and Calibri. I use them for body text at 12point because I sit a little farther away from the screen than I would read from paper (where the optimum size is 11point). The faces also all have true italics, bold, and bold italics – none of your ugly, synthetic, machine-generated rubbish! A true italic face has unique characters, which are not just a skewed regular or Roman…

The Future of EOT

Remember, these pages will work only in Internet Explorer right now, because it’s the only browser which supports EOT font embedding. EOT was a great idea for Word back in the 1990s, and it was a great idea for the Web in 1995. But because Netscape at that time adopted another standard, and we kept EOT proprietary, no-one used either.

That’s why, last year, I gathered a group of folks together and began a campaign to make EOT an open standard and put a full proposal in front of the W3C.

I really hope it will become a standard, and other browsers will also implement it, because it’s a much-needed solution to the problem of using fonts on the Web that meets the needs not only of end-users and Web designers (who get to use the commercial fonts they already know), but also commercial font creators, more of whom will start enabling embedding as a result.

We have to solve the issue of fonts on the Web in a way that’s fair to everyone in the ecosystem.

Try experimenting with EOT embedding. I’d love to see some samples from people who actually know what they’re doing…

Bill Hill
Program Manager

edit: added two additional headers for readibility

Comments (69)
  1. Damian says:

    I know this is a nitpick, but like bad code it’s one of those things that just bugs me XD

    1400 x 900 is not a standard resolution, it would lead to the not so common 14:9 aspect ratio (though not entirely unheard of). I think you mean 1440 x 900, giving the ever so lovely 16:10 aspect ratio.

  2. Bill Hill says:

    You’re right, Damien. 1440 x 900 is the actual screen resolution for which I was authoring.

    But I deliberately budgeted so I could lose some pixels to the non-functioning scroll bar which still appears on the right, and the status bar which still apears on the bottom. I built the pages smaller so I wouldn’t end up still triggering scrolling in FullScreen mode.

    If I maximize Internet Explorer on my 1440 x 900 screen, but leave menus etc in place, I get a vertical scroll bar which is active.

    When I hit F11 the menus, toolbars etc go away but the scrollbar stays in place, even though there’s no "elevator" in the shaft and it doesn’t do anything. F11 also doesn’t make the status bar at the bottom go away.

    I don’t understand why these couldn’t go away as well, and will follow up on this. Maybe there’s a good reason. But in the meantime I was being pragmatic in designing my pages smaller because FullScreen still doesn’t mean "Your content gets all the screen real estate"…

  3. Like everything else about IE, it would have been great if all this had been done years ago; that way we could be using this technology now.

    As it is, I can’t use WEFT because I don’t use Windows; and I can’t use Ascender’s tool because it hasn’t been released yet, and appears as if it will only be for fonts purchased from Ascender when it arrives.

    So in the meantime I’ll use the browser(s) which have an open implementation, with correctly-licensed fonts.

  4. kL says:

    Please, don’t push this crappy format. XORing of files is not a legal solution.

    We can already break law/leech bandwidth by (hot)linking copyrighted images, copyrighted MP3s, etc. Fonts are no different and DRM won’t help here a bit.

    Just make sure you send Referer header when you request font files.

  5. Brianary says:

    This idea is ten years old, and it was a failure then.

  6. Blaise Kal says:

    Very interesting story.

    However, please support .ttf embedding, since that’s something ALL OTHER BROWSERS have implemented or are currently implementing.

  7. Ted says:

    @kL: "XORing of files is not a legal solution."

    Uh, I don’t think you understand either the technology, or the law.  Perhaps you should study before posting.

  8. Tom says:

    Blaise appears to be unaware that Truetype is on its way out.  OpenType is the future, largely because the font foundries are migrating their old Type 1 (i.e. professional) fontbase to it rather than to TrueType.

  9. Gyrobo says:

    So what you’re saying is that you’re trying to turn EOT into the OOXML of web fonts.

    Will IE8 support @font-face as described by the CSS3 Web Fonts module, including the format() identifier as well as OpenType/TrueType support?

    Acid3 DOES require a TrueType font to be downloaded, and the other browser vendors all seem to be heading in the TrueType direction. Why delay the inevitable? Allow TrueType into your hearts!

  10. I have never really understood the legal problems with downloading fonts. I don’t have a license to use any material from the movie Hancock, but my browser displays the promotional stills from IMDB just fine.

    I realise that making a font is a time consuming activity worthy of compensation, but "protecting" fonts in a non-standard format seems counterproductive. Anyone who wants to steal the font is going to do so anyway, and it is a pain for legitimate users. Public web sites using unauthorised fonts are going to be spotted 30 seconds after they go live, so its not like enforcement is even going to be that much of a problem.

  11. Bill Hill says:

    Andrew Stephens wrote:

    "Public web sites using unauthorised fonts are going to be spotted 30 seconds after they go live, so its not like enforcement is even going to be that much of a problem."

    No, it should be no more of a problem than enforcing unauthorized downloads of music or movies…

    Is the font industry really expected to take comfort from that?

  12. Damian says:

    Thanks for the reply Bill 🙂

    I hate to say this, but my main browser is Firefox 3 and that’s what I was viewing your site with. I have no such issues with full screen in that browser, so maybe you can bug someone who would know what do do in the IE team to fix it (get it, bug them… *sigh*) .

  13. Bill Hill,

     Nothing in IE prevents people from downloading fonts, and there are already plenty of places to download unauthorised copies of any font to care to mention. What I was trying to say is that no site is going to <b>embed</b> a font that it is not licensed to use – they will get jumped on immediately in the same way that you or I would get jumped on if we used My Humps as background music on our blogs.

    The pirate sites will continue to offer the ttf files or whatever for download, nothing in Mircosoft’s spec prevents that. This "feature" just prevents legitimate sites from easily using custom fonts by embedding them in the standard way.

    Safari on the Mac (but not Windows) supports OpenType font embedded via style sheets. I have played around with it and it looks cool but adds little in the way of functionality. My guess is that most sites won’t bother with it anyway.

  14. Perhaps I should add that I am not really against the EOT standard. I guess it has its place, but Microsoft should really support OpenType fonts as well, since it doesn’t really make pirating fonts any easier.

  15. LOL says:

    1440×900… mwahahaha, look at your crappy blog with IE8 in a lower resolution and cry.

    It will be cut everywhere, horizontal and vertical scrollbars, and when you use the scrollbars, be ready to a choke, you will scroll empty content.

    This "technology" is crap as many others you trying to force. Stop pretending you innovate when in reality your are trying to cut down the web.

    Just give up on IE new crap you want to impose and start looking at acid3 test first.

  16. Chris Hunt says:

    Interesting that the first article on your blog is about how designers need to abandon print habits, and adapt to the viewer’s screen size – but the blog uses a very "printy" snaking column layout, and is fixed to 1400 pixels wide!

    Ignoring the predictable comes-from-Microsoft-so-it-must-be-evil comments, I welcome this announcement. Too long have we had to work with a handful of "web fonts", if this is the key to adding more to that list, it’s gotta be a good thing.

    But hey, let a thousand flowers bloom. If IE can support OpenType, and FF/Opera/etc. can support EOT, we’ll have the best of both worlds. Let’s try to move forward instead of fighting over "my technology is better than your technology…"

  17. Chris Hester says:

    Brianary wrote "This idea is ten years old, and it was a failure then." If you read Bill’s post he says "But because Netscape at that time adopted another standard, and we kept EOT proprietary, no-one used either." So it could have been a success if Netscape had used it. Think where we might have been today.

    Personally I’m all for any solution that gets us away from relying on a handful of typefaces such as Arial and Times. There is, however, a simpler solution. Microsoft should consider releasing several web fonts for free. These can then be installed by other browser manufacturers to ensure the font range we can use is much wider.

    Now Bill, your blog was really interesting me until I got to the second page and the Next Page link didn’t work. The last sentence was also cut off. (I even viewed the source – horror at the code!) And there were other errors, like the word "Blog" at the top overlapping the titles. But I know you and Chris Wilson are updating the code so I’ll say no more.

    One last thing. If Microsoft were to implement CSS Columns (as Firefox 2 did ages ago) then your blog could have been written to use them. An interesting read nonetheless.

  18. lsproc says:

    Out of interest, what is the difference between EOT and, or are they the same?

  19. Alex says:

    Support for EOT is fine, but it shouldn’t be the only format supported, support for TrueType/OpenType, Type 1/2 and (A man can dream) SVG fonts is also needed (WebKit supports SVG and TrueType/OpenType, Gecko looks to support the same, no idea about Type 1/2 support in either).

    I can understand MS needs support from the large font foundry’s (although I think that argument is silly, we don’t talk about embedding DRM into images in case somebody hotlinks), but it also needs to be easy for people who don’t want DRM to use their fonts (requiring them to use a Windows app to convert their fonts into a different format defeats the purpose).

    Times have changed since this issue first came up, these days you can easily find nice looking, royalty free TrueType/OpenType fonts on the web. Being able to link to them could allow a font designer to upload the fonts to his website and allow people to hot link to them via a system like Coral Cache, allowing him to issue new versions and have the changes reflected on every web page using them, as well as allowing users to download the fonts directly and loading them onto their systems for use in Word or OpenOffice (or such)

    Also, I find it hilarious that the statement “When designing for the Web, you have no clue what size of screen the reader is using” is cut off on my screen.

    Anyway, About the “ClearType” fonts, they really are beautiful, with their kerning and ligatures. If only the GDI font renderer in Windows did them justice. I hope you guys have a few dev’s porting the WPF font sub-system (which is great) to GDI. 😉

  20. Mark says:

    If you use the @font-face{ src: url(…) }scheme, does it always download the font, even when it’s already installed on the client?

  21. Alex says:

    You can reference the local copy via something like

    src: local("Font Face"), url("/font.ttf") format("truetype");

    I think the browser should cache the font, Safari re-downloads the font each time it’s used and doesn’t show anything until it loads the font, so you end up with large chunks of white space on each page load until the font suddenly appears.

  22. Ben says:

    Thank you MS for getting this technology into the hands of the W3C. I’m all for good, legal, and useful ways of supplying improved font technology and rendering to web design…and your technology will help type foundries feel comfortable in supplying their hard work for us to use on the web.

  23. Chris says:

    The second it becomes aparent that I need to boot up a virtualization of Windows within parallel to use another program besides IE6 or IE7, will be the day you lose total support.

    I am expecting IE8 to be on all Operating Systems so that I don’t have to run a PoS Windows just to view a browser. On top of that, not only do I have to have 2 copies, one for IE6 and one for IE7 because there are ways to install multiple versions of IE but also makes it unstable.

    You complete me, IE with your bastard hell rendition of life.

  24. Trevor says:

    Did I miss part of the setup required here?

    I viewed the site in IE7 and IE8 at multiple resolutions and All of them appear as if a CSS stylesheet is missing or something.

    No nice fonts, tons of blue underlining, clipping, overlapping.

    There’s also a "This Tab has been recovered" message that pops up… what is that all about?

    I also noticed in IE8 that it messes up IE internally.  Check out the Internet Options and click on the advanced Tab.  Where did all the radio/checkboxes go?

    If you highlight the text, there is a flash of the text that occurs before the final highlight… sorta like a bold-unbold issue.

    PS will these fonts work properly with the FuzzyType turned off?  Most of us have no intention of turning this feature back on until it is fixed.

    Oh great! now IE8 is completely locked up!

    Nice feature! Not! – Epic Fail.

  25. What gives says:

    What is with all the VML crap in that page? Where in the W3C standards is VML? I only see SVG?

    And whats with the MSO styles? did you use the saveas feature of Word? (#1 no-no in Web site design)

    Man I thought the sample code posted last week was crap, this stuff takes it to a whole new level!

  26. Ain says:

    EOT is another dead end of Microsoft’s developments and just goes to show that the Redmond giant is still executing its closed format ideology.

    WebKit has had the proposed CSS 3 Web Fonts support for almost a year now and is surely <a href="">leading the run for CSS3 compatibility</a>.

  27. Steve says:

    2 Things:

    1.) The "embeded" font thing suffers from this bug in IE:

    Whereby it causes additional redundant and annoying statusbar messages for single downloaded items.

    Since this bug is marked "won’t be fixed in IE8, ‘will likely never ever be fixed’*** "

    2.) The "requirement" for a site to have a 1400px horizontal resolution in order to be viewable goes against Sooooo many rules of web design it isn’t funny.  If your site doesn’t render at 1024×768 without issue, YOUR design needs to be fixed.  CSS provides some very nice features for handling screen sizes, and a sprinkle of JavaScript can work magic, in transforming a 1 to 2 to 3 column layout by screen width for optimal display.

    3.) DOCTYPE.  There’s no excuse anymore.  Not adding one indicates a non-interest in pushing new technology on the Web.  IE/Lack of Doctype is exactly what is holding back the Web.

    *** Global interpretation of "we will consider this for a future version of IE"

  28. Joe Clark says:

    Your site still has the same invalid HTML you advertised as having been fixed. On the plus side, this page’s stylesheet is at least readable, unlike the white-on-black horror on your old blog.

    A typefoundry with whom Microsoft has a sales relationship should not be called “prestigious,” for it leads people to accuse you of a conflict of interest. So: You have a conflict of interest.

  29. billybob says:

    "Three versions of the EMBEDDEDFONT have been defined to this point. The second and third add additional data at the end of the structure, just before the "FontData" entry."

    Shouldn’t you decide on one format if you are going to make it part of a spec?  Also why does the submission mostly link to for its definition?  Shouldn’t everything be in the actual spec so that things cannot be changed on the fly.  Not that I would ever suggest Microsoft would change standards…

  30. Faramond says:

    Why not release a second set of core fonts for the web (but this time with more Verdanas and Georgias and fewer Comic Sanses and Webdings.) That would be a much more elegant (i.e., standard OpenType, supported by all browsers, single-download) solution than what you propose with EOT.

    I understand that fonts are costly to develop, but why not team up with Apple, Adobe, Google, possibly a Linux vendor or two to develop them? You could split the cost! Alternately, how much would it cost for other browsers to adopt EOT? It might be less expensive for them to pay for the creation of new web fonts.

  31. Mitch 74 says:

    Gasp! No wonder C.Wilson wanted to throttle you! I haven’t seen code that atrocious ever since I corrected a webpage created under Word 97 – and ended up shaving off 95% of the code and rewriting most diagrams.

    Then, looking as I’m using Firefox 3 on Linux, the MS fonts aren’tavailable to me – and your webpage ends up with boxes overlapping each other really, really badly.

    Your design, as said, isn’t fluid at all.

    Now, EOT becoming a public standard isn’t a bad thing, as long as the anti-copy algorithm is public too (so that anybody can write a ‘font protector’), like SSL is (a good encryption algorithm can be open, what is encoded with it _requires_ the key – if it requires obscurity be efficient, it isn’t good). Will that be the case?

    Moreover, what will be the advantage of EOT over TrueType for unprotected fonts? None? Then support websites using embedded TrueType fonts. It can’t be that difficult.

  32. I think this is a dream that can become true but it won’t be good!

    Just imaging how many website you browse and check everyday?

    do you realize how much space you will need to store the installed fonts from the internet browsing?

    that’s only if you will open a professional websites, what about the poups and ads and the other websites that we just check for fun!

    i say it’s a really good idea but i would like to see how it’s implemented!



  33. Jon says:

    So what you seem to be saying is, ten years after you went one way and Netscape went another, leading to nobody using either approach, the rest of the web community has gone way and now you’ve decided to go another? We’ve come such a long way! I guess everyone will just carry on using sIFR then.

  34. Jon says:

    So what you seem to be saying is, ten years after you went one way and Netscape went another, leading to nobody using either approach, the rest of the web community has gone one way and you’ve decided to go another? We’ve come such a long way! I guess everyone will just carry on using sIFR then.

  35. Hi Bill,


    <![if !vml]>


    <!–[if !vml]>

    …and that will fix a lot of the validation errors on your page.  😉

  36. Gyrobo says:

    I’m sure after cleaning up Bill Hill’s site, Chris Wilson will demand the immediate implementation of multi-column layout.

    Please? You can add a proprietary prefix, everyone else is doing it…

  37. TheSteve says:

    "They were designed to be viewed on…", you’re kidding right?

    These days the only thing we should be requiring is an internet connection!

    Please read: and get back to us.



  38. TheSteve says:

    Pardon me.

    I should have prefaced that last comment with a caveat "no slight intended by the title of the linked page".

    It’s just been a long time, thankfully, since I’ve seen a "this site is best viewed in.." type of message.

    I flashed back to 1999.



  39. thacker says:


    It would help if fonts from folders in addition to the Windows Font folder could be referenced within the WEFT tool — font management applications.

    Possibly include font link, in addition to EOT, within IE8. Let the market decide the value. But then conditional comments can be used to support both.

    Without getting into specifics, copyright infringement for justification of only EOT is pretty weak. Sell the positive benefits of its use and include a major overhaul of the WEFT tool.


  40. Velveeta Dentata says:

    This is a joke.  First of all, this page should never even have been release *UNTIL* the code was valid.

    And then you link to a three column layout that can only be viewed at 1440×900? This is truly and utterly pathetic. You just don’t get it.

  41. Maguire says:

    What a waste of HTML! What the !@#$ was that code written in? Microsoft Bob?

    *shudder* that is some damn ugly code I’m surprised it even rendered at all.

    I’m not sure what technology you were trying to sell but it got lost in the tag soup catastrophe that that site contains.

    Spend a few minutes with HTMLTidy and the W3C before posting please.

  42. Ahmad Alfy says:

    Thumb up for Joe Clark and TheSteve!

    Bill, How did you publish that page with the way it look? and what exactly did you use to make this … I dont know what to call it, thats not a webpage

    I need some air, This code hurts my eye!

  43. Alex says:

    "So what you seem to be saying is, ten years after you went one way and Netscape went another, leading to nobody using either approach, the rest of the web community has gone one way and you’ve decided to go another? We’ve come such a long way! I guess everyone will just carry on using sIFR then."

    IE (and Netscape) used the CSS standard to implement this, but neither used the fonts specified in the spec.

    This has changed in CSS3, if you check the CSS3 fonts draft you’ll see it references the Embeddable OpenType format MS created, so you can’t say this is some MS only "screw the standards" action like they used to love.

    What they need to do is also implement the other formats specified in the spec, eot can’t be the only format, at a minimum plain truetpye is needed as well.

  44. Eden says:

    I’m curious… IEBlog has been a good discussion place for future features of IE. Where are those people bashing MS and IE from?

    Font-embedding can be beneficial to many web designer. However, font industry cares if MS "suggests" people simply spreading fonts around the Internet.

    I agree his blog sucks (oops). So can we stop talking about his blog? Thanks.

  45. Jeff L says:

    Aside from being an atrocious site, the fonts look fine on Firefox, because I’ve actually got Cambria on my machine. So unfortunately your example is lost on anyone who already has that font.

  46. Richard Fink says:

    @Joe Clark

    I take issue with one thing you write on your blog re: Bill Hill’s posting…

    "The only people who are going to want to use Web fonts are Macintosh standardistas, and they’ll demand good code."

    If you are referring to the kind of download-on-demand EOT font packages to which Hill refers, I don’t think many authors are going to accept the additional hassle and download times. I agree.

    However, the desire for a wider range of fonts for use in Web pages is certainly widespread, if latent. Historiclly, there is seldom a clamoring in advance of anything that, once available, quickly achieves widespread use.

    (Did you need or want an "Internet" in 1985?)It’s impossible to do accurat market research for somehing that does not as yet, exist.

    I’m not a designer but I’ve seen my own bare-bones pages transformed by just a sprinkling of Photoshop text in a contrasting font.

    And no standardista, I, either.

  47. Brett Merkey says:


    I have used font embedding via Weft for a long while and all I can say is this article, along with an absolutely clueless blog site, have set acceptance of this technology back prodigiously.

    There is a real need for embedded font technology appropriate to Web sites and Web applications. I believe Microsoft has a viable approach — but you would never come to that conclusion on the basis of this unfortunate article.


  48. Blaise Kal says:


    >Blaise appears to be unaware that Truetype is on its way out.  OpenType is the future, largely because the font foundries are migrating their old Type 1 (i.e. professional) fontbase to it rather than to TrueType.

    .ttf (TrueType) was just an example. OpenType is of course fine too. Anything but EOT, which is only supported by Microsoft and would take years and years to become a standard, if ever.

  49. Lambros Vasiliou says:

    Great work on pushing embedded fonts I have been waiting for this for long now!!

  50. Garry Trinder says:

    My comments on font embedding – and response to some of these comments – are at my new blog, at

  51. Jason says:

    Could you just implement CSS @font-face rules to make it easy for everyone? WebKit/Safari already does this. It makes it so much easier for developers and it is a standard.

  52. @Jason – as a matter of fact, we implemented CSS @font-face rules TEN YEARS AGO.  Pay attention.  

  53. Although this idea sounds almost as cool as embedding videos sounded several years ago, it will most probably become a general "no-no" for the standard website designing as the sound and music embedding became.

  54. Donal says:

    For someone who very validly states

    “When designing for the Web, you have no clue what size of screen the reader is using”.

    To then go on and state that

    "They were designed to be viewed on a 1400 x 900 display, and should be viewed using the F11 key to make Internet Explorer go FullScreen, to get rid of menus, address bars and anything else that distracts from reading."

    is rediculous.

  55. genenbottle says:

    Are their any plan on adding tags in favorite.

  56. Nobody says:

    was XORing data considered secure 1996?

  57. None of the browsers I tested (IE8B1, Gecko 1.9, Safari 3.1, Opera 9.5) support focus/outline for checkboxes. This is pretty lame considering it’s one of the most difficult elements to determine if it has focus or not (when I press the spacebar to check it as I always do).

    This makes me wonder…do browser vendors maintain a static list of elements and handpick what they decide they will support (selectors, properties, values, etc) or are any of the engines setup so that this stuff should automatically just work based on a dynamic cross reference?

  58. Charlie says:

    So Beta 2 is due in August, and RTM before 2009.

    This doesn’t leave much time for Beta 3!

    Are we going to see any fixes after Beta 2? or will this be a release where you tell us that’s it! Any other features / bug fixes will have to wait until another release?

    I Seriously hope there is a Beta 3.  Beta 1 was an Alpha, and didn’t live up to expectations (except for CSS 2.1, and finally "some" better DOM support)

    Still fails the grade on a being a real worthy browser ATM.

  59. Ben Darlow says:

    Joe Clark more thoroughly deconstructed the article above than I think any of the rest of us could hope to, but I am still left with questions based on the comments above by Chris Wilson.

    You state that Internet Explorer has supported @font-face embedding for ten years (and /get with the program/ etc. etc.), but isn’t this only the self-same EOT embedding that nobody uses or cares about, rather than TrueType as now supported by Safari?

    I agree that directly linking to system-installable font files is a messy solution, but contrasted with what is effectively an obfuscation wrapper around fonts, created using proprietary software, it’s easily the better one.

    What possible reasons do Microsoft have for not implementing support for embedding TrueType (or even OpenType) fonts via the @font-face CSS declaration? Could you at least explain that?

  60. Ralph says:

    I can’t believe there is an entire thread dedicated to the argument over a non-standard font issue, when developers would much rather see features they care about added to IE.

    How about some OPACITY people!? (the CSS property that is, we’d like TRANSPARENCY from the IE team)

    How about some improved DOM support for Select and Table elements, why must these be soooo broken?

    How about addEventListener? We realize this spec has only been around for like Two-Thousand-And-Five-Hundred days or so, but surely support must be almost ready now?

  61. Glen says:

    "What possible reasons do Microsoft have for not implementing support for embedding TrueType (or even OpenType) fonts via the @font-face CSS declaration? Could you at least explain that?"

    I think by not doing that they’re trying to get the other browser makers to support EOT. Time is money, and they already have something that works.

  62. anony.muos says:

    Why is that utility web-based and not downloadable?

  63. Karthik Ram says:

    This is all great..but as GM do you / MS have any plans / dates as to when MS will retire IE 6? If so, can you share them?

    Like an automatic update that would remove it? Something that will make it stop working? I am getting ready to start using IE 8 technologies for serious development, but it is increasingly difficult to ensure cross-browser compatibility of 3 different versions of A browser.

  64. Karthik Ram says:

    This is all great..but as GM do you / MS have any plans / dates as to when MS will retire IE 6? If so, can you share them?

    Like an automatic update that would remove it? Something that will make it stop working? I am getting ready to start using IE 8 technologies for serious development, but it is increasingly difficult to ensure cross-browser compatibility for 3 different versions of A browser.

  65. EricLaw [MSFT] says:

    No, IE6 will never be removed by "automatic update."  It will eventually fall out of support, on the schedule outlined here:

  66. thacker says:


    Tried my hand at use of EOT via the font-face rules.

    This page is a partial reproduction of a Texterity online magazine publication. Texterity is a service that uses a propriety technology to deliver exact reproductions of a client’s print magazine to a Web browser.  The problems with these specialized types of delivery are self evident.

    EOT was well suited for this. Since EOT EULAs are up in the air so to speak, Calibri and Cambria were used rather than exact duplication of the publication typefaces. Font-face rules have been specified using an external style sheet within conditional comments. Partial subsets were used. XHTML 1.1 custom, CSS 2.1, Priority 3 WCAG 1.0, blah blah blah compliant. The CSS could have been done much better by someone who is much more proficient than I.

  67. IEBlog says:

    Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approached

  68. 안녕하세요 Bill Hill 입니다. 웹에서의 폰트를 인쇄물과 같은 수준으로 높이기 위해 노력 중 입니다. 이번 주에 커다란 진전이 있었습니다. 미국의 유력 폰트 배급업체가 Embedded

Comments are closed.

Skip to main content