Serving web sites with embedded fonts
By Sergey Nosov
February 24, 2014
Many web designers today choose embedding fonts in web sites. When certain text has to render in a certain font—due to artistic vision, corporate requirements, or any other reason—using an embedded font is the cleanest most straight forward option, barring which designers have to resort to such workarounds as rendering text with images or through browser plugins and vector graphics.
Embedding fonts is not new. Earlier technologies were vendor specific, such as Web Embedding Fonts Tool (WEFT) or Compatibility Web Type (CWT) with .eot files from Microsoft and TrueDoc .pfr from Bitstream supported by Netscape browsers.
These days we are experiencing resurgence in web embedded fonts, thanks to a more uniform support across popular browsers, and to such services as Google Fonts, Adobe Edge and TypeKit, WebINK, Fontdeck, Webtype, Typefront, Fontspring, Fonts.com by Monotype Imaging, Typotheque, and others.
Most of the services will host fonts for you. All you have to do is include links to their servers. Some designers, however, prefer to host all content required by their web sites themselves, including fonts. Running such web sites under Internet Information Services (IIS) version 7.5, which is a part of the Windows 2008 R2 Web Server, may be problematic. Font technologies desired today had not been fully standardized by the IIS 7.5 release.
In this article we will show you how to easily configure IIS to serve web sites with embedded font files without errors.
Modern web sites with embedded fonts call for files in one or more of the several types listed:
| Name | Extension | IIS 7.5 Pre-configured |
|---|---|---|
| TrueType | .ttf | Yes |
| Embedded OpenType | .eot | Yes |
| OpenType | .otf | No |
| Web Open Font Format | .woff | No |
The last of which, Web Open Font Format (WOFF), currently enjoys the most prominence and is recommended by the World Wide Web Consortium (W3C).
So, what happens when IIS hosts a web site that tries to use a not configured font type? The web designer is likely to not notice that anything is wrong, as he or she has the web browser serving a locally installed font. Web site visitors, probably, do not know beforehand what font to expect, and may be unaware that something does not look as it is supposed to, when their web browsers substitute web fonts with fonts installed on user computers.
Yet, while examining the web site logs, you may notice that when visitors request font files, the web server replies with HTTP error 404. This is because the web server software does not know the Internet media type or MIME type of the files being requested. Fortunately, this is very easy to fix.
Open the IIS Manager, and click on your server home node in the Connections pane on the left. In the features view in the middle, under the “IIS” group, find and double click on the “MIME Types” feature.
A list of file extensions and associated content types opens. In the Actions pane on the right click on the “Add…” action. The Add MIME Type dialog pops up. Use this dialog to add all the missing MIME types one at a time.
Furthermore, the IIS 7.5 out-of-the-box configuration specifies .ttf and .eot files MIME types as ‘application/octet-stream’. If you wish to keep current with official recommendations, the following table lists the most up to date (as this article was written) font Media Types registered with Internet Assigned Numbers Authority (IANA):
| Extension | MIME Type |
|---|---|
| .ttf | application/font-sfnt |
| .eot | application/vnd.ms-fontobject |
| .otf | application/font-sfnt |
| .woff | application/font-woff |
In IIS manager, double-click on the associations you want to edit, and change the MIME type as appropriate.
This should be it. Try loading web sites with embedded fonts, and check the log files to make sure you no longer get the 404 errors. Also try loading the web sites from computers that do not have the same fonts installed, and observe if web browsers correctly render the embedded fonts.
Good luck.