Internet Explorer @Font-Face Is Failing

@font-face not displaying correctly in IE

Multiple font formats

To support a wide range of browsers, use a .ttf, .woff and .eot version of the font.

@font-face {
    font-family: 'shardee';
    src: url('fonts/Shardee.eot');
    src: url('fonts/Shardee.eot?#iefix')
             format('embedded-opentype'),
         url('fonts/Shardee.woff') format('woff'),
         url('fonts/Shardee.ttf') format('truetype');
}

You can use a Font conversion website like Font Squirrel, to convert the .ttf font into .woff and .eot.

DRM false positive

As @Jukka pointed out, there's a legal issue with the TTF file that's preventing it from being usable in Windows. In the IE developer console, the following error message is displayed :

CSS3114: @font-face failed OpenType embedding permission check.
Permission must be Installable.

Shardee appears to be an abandoned font with an unknown license type. Although it may be legal to use this font, Windows seems to require that every TTF file has DRM info that explicitly says it's legal to embed it in web pages. The error in IE is most likely a false positive.

To test this, I took a TTF font that's known to be legally licensed for use on websites. The TTF version didn't work in IE because of the DRM error. This example is definitely a false positive. This is one of the reasons why it's necessary to use multiple font formats, and why a single format like TTF will not work on all browsers.

Although Windows doesn't allow IE to use the TTF file, IE can still use the WOFF or EOT version. When I tested the above @font-face rule on a local webserver, using all three font formats, the Shardee font rendered correctly in all versions of IE (though with an error message in the IE developer console).

Steps to try:

1. Convert the .ttf file to .woff and .eot
2. Upload the .woff and .eot files to the same directory as the existing .ttf file.
3. Replace the @font-face rule with the one above. I fixed a couple typos in the initial version of it.

If you still have a problem, there may be an issue with the web server settings. Related question: IE9 blocks download of cross-origin web font

On IE CSS font-face works only when navigating through inner links

I found a solution but I cannot see the reason why it works (well, only one reason - it's IE :D).

What I did was to put the same site on Apache and test again. On Apache the fonts worked fine even when using Refresh button. Then in the network inspector I saw that Apache is returning 304 instead of 200 for the eot file and it hit me - so it's caching issue. I went to my ASP.NET app and sure enough - for security reasons (and also to avoid caching AJAX requests) someone had disabled every caching you could imagine:

        // prevent caching for security reasons
        HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(false);
        HttpContext.Current.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
        HttpContext.Current.Response.Cache.SetValidUntilExpires(false);
        HttpContext.Current.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
        HttpContext.Current.Response.Cache.SetNoServerCaching();

        // do not use any of the following two - they break CSS fonts on IE
        HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
        HttpContext.Current.Response.Cache.SetNoStore();

As soon as I commented out the last two lines of code, suddenly fonts started to work without problems on IE. So I guess the answer is: IE cannot load the font if it is not cached. I have no idea why the problem happens only when refreshing/navigating back, though.

Edit - Alternative solution

Instead of commenting those last two lines

    // do not use any of the following two - they break CSS fonts on IE
    HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
    HttpContext.Current.Response.Cache.SetNoStore();

Change the SetAllowResponseInBrowserHistory to true instead:

HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(true);

This should still allow no-cache with the exception of back and forward navigation as I understand it.
MSDN - SetAllowResponseInBrowserHistory Method

Related Topics