You could say I’ve become somewhat obsessed with @font-face embedding over the past few months. I’ve most certainly fell head over heels for the @font-face generator from fontsquirrel.com (see the recap below).
One thing however that has always bothered me is IE7 and IE8’s rendering of embedded fonts, so today with IE tester at hand and google ready to get wild I vowed to come up with a solution and I think I may just have.
If you haven’t already read my previous postings on @font-face I’d like to direct you to the following two posts:
When embedding using @font-face IE6 (surprisingly) renders the type face perfectly as does Firefox and Safari but IE7 and IE8 serve up a sub-standard jagged font face that is really not pretty to look at.
Take a look at the first demo page for a simple example of a custom font-face that has been embedded. If you can, take a look at this page in both Firefox and either IE7 or 8 to see the difference.
After much research I discovered the problem was being caused by Microsoft’s ClearType functionality. ClearType is designed and very much works to make rendered text online and throughout the windows system clearer to read. That’s great for body text and like I say it does work but when it comes to custom fonts that have been embedded ClearType is attempting to do a job which isn’t needed. This is what gives us the sharp, jagged looking font face that we don’t want. Because we want nicely anti-aliased text like we see in Firefox, IE6 and Safari.
As a side note I’m assuming that IE6 never had the functionality to render ClearType functionality and uses some other sort of properietary technology, leading to nicely embedded fonts in IE6 in a perverse sort of way.
Update: For IE6, Windows XP does not force ClearType on in the browser and Windows Vista was shipped with IE7 pre-installed (falling into the bracket of our fix) therefore the risk of IE6 users being exposed to ClearType issues is minimal.
The good news is that there is a way to disable ClearType via the browser when visitors are viewing your web site. Now I’m not recommending this for any other use than what I’m demonstrating today, in general ClearType gets it right and helps visitors read your site the way it was meant to be read. Disabling ClearType in most circumstances leads to horribly rendered body text and a whole help of problems for your visitors eyes.
The process of disabling ClearType
Internet Explorer as a rule do not apply ClearType to elements using their proprietary CSS filters as they can conflict and result in wider issues for the browser so we can exploit this to make Internet Explorer leave our embedded fonts alone. Now unfortunately there a few subtle differences between the browser that mean we can’t simply apply a useless filter and move on.
Take a look at the second demo page where I’ve added a few additional fixes for IE7 and 8. Go ahead and take a look in both Firefox and IE7/8, you should now find a much nicer rendering of the font in IE. I’ll break down what’s been added below.
The crux of the fix:
h2, p {font: 36px/44px 'OldSansBlackRegular', Arial, sans-serif;letter-spacing: 0;filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=hIEfix.png,sizingMethod=crop);zoom:1;}
The above snippet of CSS fixes our smoothing issues in both IE7 and IE8 as seen in the previously linked demo page. The key to this is filter CSS property and the zoom property which are only applicable to Internet Explorer.
Looking at the filter property
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=images/headers/hIEfix.png,sizingMethod=crop);
This part is mostly for IE8, both IE7 and 8 need to have a filter present to disable ClearType but IE8 has to have this filter actual doing something to recognise it. I also noticed when testing that without a background image being present in IE8 the ClearType disable had little effect. So what this filter property does in effect is kill two birds with one stone. We add a filter which checks the required boxes for IE7 and 8 as well as adding a one by one transparent png image to satisfy IE8.
Looking at the zoom property
zoom:1;
This is solely for IE7. It fixes an issue with hasLayout. If you don’t know anything about hasLayout then not to worry. Essentially IE filters can’t be assigned to any element that doesn’t have ‘layout’ so the zoom:1 property gives our headers ‘layout’. hasLayout is only applicable to IE version 7 and lower as it was dropped from IE8 (thankfully). To learn more about hasLayout see here.
So in future when embedding fonts using @font-face you can use two simple IE only CSS properties and a 1 by 1 transparent png to give your fonts that anti-alias effect in IE7/8. You can even place these two properties in a separate IE only stylesheet as we are doing nothing else apart from tweaking the styles.
Just to note that as with any workaround you’ll need to test this on a site by site basis to ensure the fix is giving you the results you want. Even with this tweak font rendering in IE can still be unpredictable so testing and constant tweaking is a must!
Your viewing this article on allcreatives.net – the web design focused blog.
Update : Follow up post on ClearType issues in Firefox and Safari.
Paul Irish
December 5th, 2009
Very interesting technique.
I know a lot of typefaces are hinted specifically with ClearType in mind, so I don’t know how well this recommendation would work on all fonts. That’s something to explore. (Like how it would fare on TypeKit’s roster)
The other thing that catches my eye is AlphaImageLoader. It’s criticized heavily for being slow and a memory hog, so I think we could use another IE filter.
Opacity would be a choice as I’m fairly certain it’ll disable ClearType and also be fairly performant amongst the filters.
IE8 changed up how the opacity syntax works, so something like this should be a good bet:
-ms-filter: “progid:DXImageTransform.Microsoft.Alpha(Opacity=100)”;
filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=100);
Again, it’s a very clever approach, but as always, it should be tested against the particular typeface you want to use. 
Mike
December 5th, 2009
Thanks paul.
Regarding the filter choice, I did initially test with the opacity filter but found this to fail almost all the time in IE8. As I mentioned in the post IE8 seems to have an issue with no background image being present when targeting an element directly. Wrapping the embedded font in a holder div and then applying the opacity filter seems to do the trick but this adds messy excess code to each instance of the embedded font(s).
Cheers for the links though I’ll take a look as I’m sure I’ll be updating this post in the near future and if I can eek out some performance improvements I will.
oh and yes, testing font by font is a must.
Christof
December 5th, 2009
I just tried your demo on IE8 and FF3.5 in Win7 and BOTH render the somehow jagged text when activating cleartype. So actually the IE “fix” would not be enough, FF shows the same problem. The underlying problem should be somewhere else I guess, as only certain fonts show this strange behaviour.
James Puckett
December 5th, 2009
“I know a lot of typefaces are hinted specifically with ClearType in mind…”
Rubbish! Very few typefaces have ever been hinted with ClearType in mind. You would be hard-pressed to find any typefaces hinted for ClearType other than those that have been commissioned by Microsoft (Calibri, Constantia, Gabriola, etc.). Microsoft has done a very poor job of really even explaining how their different rendering systems even work and how to develop type that looks good on Windows, and TrueType hinting is generally a PITA, so most commercial fonts are fonts hinted with the Adobe auto-hinter for Postscript and are not even available as TrueType hinted fonts.
Font Squirrel
December 5th, 2009
This ties directly into the research I’ve been doing myself. I can tell you that a lot of the fonts that are hinted for ClearType, do indeed look bad when it is turned off. I saw this starkly on the FontFont fonts on TypeKit.
The technique seems limited to larger display sizes as smaller type seems to degrade a bit. Good job with the forward thinking!
Paul Irish
December 5th, 2009
Ah! Tricky tricky.
Nice work.
Vladimir Carrer
December 5th, 2009
Interesting technique. But, I generally disagree about the Clear Type disabling . I actually like how Clear type renders fonts. Here are some research saying that Clear type generally improves readability http://www.ischool.utexas.edu/~ct/ also PDF http://www.ischool.utexas.edu/~ct/chi_p618.pdf
Charles Roper
December 5th, 2009
Firefox 3.6 beta 4 is rendering poorly on my Vista machine. Have a look:
The problem with ClearType (when rendered using GDI, which is most of the time) is that it does not anti-alias on the Y-axis.
Here’s a great explanation.
In that article, they’re explaining how WPF improves on GDI by doing Y-axis anti-aliasing in ClearType. It’s a marked improvement. The bad news is that WPF never really took off. The good news is that DirectWrite, a new Direct2D-powered rendering engine, is being incorporated into IE9 and Firefox 3.7; so on most post-XP based operating systems, fonts should, hopefully, start to looking better.
Some further reading:
Better Postscript CFF font rendering with DirectWrite
On that last one, click the Calluna sample image to get a larger view. It really does show-off how much better DirectWrite looks, in this case.
James W Cready
December 5th, 2009
Another way to disable ClearType is to specify the font-weight property to any number.
IE seems to completely disable ClearType if you haven’t set your font-weight to one of: normal, inherit, bold, bolder, or lighter. If you set you font-weight to, say 800, IE will still render it as bold, but there will not be any ClearType.
Electricspace
December 5th, 2009
hi,
I guess you can do something like this as well to cancelcleartype:
-ms-filter: “progid:DXImageTransform.Microsoft.DropShadow(offx=0, offy=0, color=’#ffffff’, positive=’true’)”;
Ryan
December 5th, 2009
Nice find, good to see the it’s an easy fix too.
Dan
December 6th, 2009
I’ve viewed the font face demo in both firefox and IE8 but they both look sharp and jagged. I’m using Firefox 3.5.5. Any ideas why I’m not seeing the smoother version in Firefox?
Cheers.
Mike
December 6th, 2009
To all, thanks for the feedback and interest, some really good information being collected here and I’ll be reading through it all and see if there any improvements to be made on the existing fix.
@Vladimir Carrer – I agree and I think I mentioned in the post that under normal circumstances disabling ClearType is not advisable that’s why this fix only targets elements containing embedded fonts.
@Charles Roper – This is an issue with ClearType being enabled system wide when embedding TTF’. Strangely ClearType doesn’t cause any issues when embedding OTF. I’m looking to write a follow-up post on this subject with hopefully a further fix this week. Also thanks for the links I’ll be sure to check them out.
@James – Really? This sounds very promising I’ll be sure to do some testing and see if anything can be done with a simple font-weight property. Quite honestly it’s something that I haven’t seen suggested anywhere else.
@Dan – Please see my response to Charles Above.
James Puckett
December 6th, 2009
Really, Mike. But that doesn’t mean it’s going to stay that way. Right now foundries are all backing up the queues of hinting professionals (there aren’t many people who can hint TrueType fonts cost-efficiently) to get their fonts ready for web use with IE. And people are also starting to convert autohinted PS fonts to TT fonts (it works really well with light weights and sans type). But OTOH, Microsoft seems to be moving to Directwrite rendering for IE 9, which (I think) means that IE 9 will be able to render all forms of hinted type effectively. How this will all fall out in the next few years is quite unpredictable, so web developers should make sure that their code will be easy to change down the road!
Mike
December 6th, 2009
Sorry James, crossed wires there I think. I was actually replying the second James’ comment but regardless the extra info is still appreciated.
Alex
December 10th, 2009
DirectWrite produces much nicer results than GDI, but the problem isn’t so much in the anti-aliasing, as it is in the hinting.
http://localhostr.com.nyud.net/files/425a76/allcreatives%20-%20DW.png
DirectWrite still has certain throwbacks to GDI style rendering (look at the D in December), but once you go outside those limitations text is absolutely beautiful (A cheap hack to disable font hinting for DirectWrite is to apply a very small rotation to the text, 0.0001 degrees is enough to disable hinting but will keep the baseline alignment).
h1,h2,h3 { -moz-transform: rotate(0.0001deg); }
Although the only proper way to bypass hinting, is to remove the need for it all together, If the device rendering the text was a higher density (most PC screens are around 100dpi, my printer is 6 to 12 times higher than that) then you wouldn’t need to hint at all, and hinting would actually worsen the shape of the glyphs in that case.
As for the font in the demo, I just don’t think it’s hinted very well, the bottoms of the glyphs seem to pull down to the base line, producing square bottoms, disabling hinting instantly produces a nicer result.
max
December 11th, 2009
Nice find, good to see the it’s an easy fix too.
Jonas
December 11th, 2009
Thanks a billion for this post. I remember the Microsoft’s ClearType functionality to be a monkey on my back a couple of weeks ago. Didn’t fix nor touch it since.
zhangxinxu
December 12th, 2009
It’s really a very nice post. I decide to translate it.
Jason
December 14th, 2009
eeeeeh and here I was thinking there was no fix for this! Thank you!
Sara
December 18th, 2009
That is just awesome!
You are my hero for figuring this out!
tanya singh
January 19th, 2010
awesome dude, thanx
