When embed fonts don’t look as good as you wish.

[Edit] : Since Chrome and Firefox changed their engine to render fonts, this article may be a bit outdated. But still interresting.

The problem

Font-face is an authentic antiquity off the world wide web. Microsoft introduced it 15 years ago, in October 1997 with the 4.0 version of its browser. With the implementation of a new rendering engine: trident.

In the begined font-face met a very limited success for a bunch of technical reasons. In my opinion, the main reason for this failure was the weight of an embedded font. In these times, a web page that weigh more than 100 kb was considered a heresy … so add 50 kb of font doing was no acceptable.

Today, other browsers have implemented it, and in a much better way than the first version. Internet brandwith have increased considerably so font-face became a very popular practice. The designers have started to pay more attention to the font rendering in the different browsers … and it soon became a real headache. Especially for large body (18 +) wich is what I’m talking about in this article.

An excellent article in Smashing Magazine explains why and how rendering problems occurs. Each browser uses a rasterization engine (to convert vector fonts in pixels), and that is not necessarily the same for both types of contours. These contours can be TrueType (TT-webfonts) or OpenType / CFF (PS-webfonts). Here’s an article on Adobe’s blog to explain the differences.

Mac os, is not concerned by this rendeind issue since all browsers use quartz to render fonts. On Windows, this is not the case. Each browser chose his rendering engine. Just below there’s a table from the article that summarizes the rasterization engines depending on the browser and type of font.

Overall, DirectWrite works well for both types of fonts, but the result is not exactly the same. CGI ClearType only supports vertical antialisating and not horizontal antialisating and therefore has a very different look than GDI grayscale.

The result can be quite dramatic depending on the font. The following screenshot show the home page of [http://www.google.com/webfonts “ target=”_blank”>google webfont) in different browsers :

I’m not a fan of the rendering for Arial in IE10, but for the rest it is better than chrome and firefox. I’ve always wondered how this is possible that google does not something to improve the rendering of their own fonts in their own browser.

The concern is not the type of rendering in absolute terms, it is to have the choice. Rendering soft and very antialiased over 16 points and sharper below.

Thesolution

As Typekit explain it in [http://blog.typekit.com/2011/07/26/new-from-typekit-improved-font-rendering-on-windows/">this article), the solution to this issue is to serve webfonts with Postscript outlines.

/!\ If you have already read somewhere to use svg fonts in chrome… forget it immediately. Rendering is good letter by letter, but you risk a large number of bugs in a paragraph.

Start by downloading a font from google website. I took the first one (Sanchez). You obtain a file : Sanchez-Regular.ttf. The first step is to convert it in .otf with PS outlines via a software like [http://www.fontlab.com/font-converter/transtype/" target=”_blank”>TransType). To ensure that the conversion has been done correctly, you simply open the file with Windows font overview. Here is a screenshot of boths versions .ttf and .otf.

Normally, you should see a clear difference between the two. The version with TrueType outlines should be pixelated, while the version with postscript outlines is smothly anti-aliased. In the header of the police, the outline type is specified.

Then, you go to the [http://www.fontsquirrel.com/fontface/generator" target=”_blank”>font-face generator of font squirrel) to create a kit. You should do so to generate the .svg and .eot fonts. Once the kit is created, you have the files in .eot, .woff, .svg and .ttf. This generator does not handle outline PS, so to generate .woff file, we use another.

• The .svg file will be used for iOS.
• The .eot will be used for old versions of ie.
• The .woff file is useless, discard.
• The .ttf is useless, discard.

(The useless files can also not be generated by checking the appropriate boxes in the generator)

Now you are going to generate a .woff file with postscript outlines. To do this, you use a little software : [http://people.mozilla.com/~jkew/woff/ “ target=”_blank”>sfnt2woff). Download the precompiled version for Windows. You get a small .exe on which you drag & drop your .otf file. Woff will be generated.

Results and integration

So you are ready for integration and have the following files :

• a .otf font =>; from the conversion of the original .ttf file via a software like TransType.
• a .woff font =>; from the conversion of your .otf file via sfnt2woff.
• a .svg font =>; from fontsquirrl generator.
• a .eot font =>; from fontsquirrl generator.

Summary of each file target :

You can now proceed to the integration in the code :

@font-face {
    font-family: 'sanchezregular';
    src: url('sanchez_-webfont.eot'); /*A*/
    src: url('sanchez_-webfont.eot?#iefix') format('embedded-opentype'), /*B*/
    url('sanchez_-webfont.woff) format('woff'), /*C*/
    url('sanchez_-webfont.otf) format('opentype'), /*D*/
    url(''sanchez_-webfont.svg) format('svg'); /*E*/
    font-weight: normal;
    font-style: normal;
}

The order is very important. The browser will take the first thing it’s able to understand. You can now use ‘sanchezregular’ for the font-family property in your CSS.

A : for ie 6 and older
B : for ie 7 & 8
C : for modern browsers
D : for less modern browsers but which can use otf
E : for iOs

Conclusion

Here is an animation that shows the differences between rendering obtained with the .ttf font with TrueType outilnes and the .woff font with Postscript outlines (Opera behaves like firefox) :

You can remenber several elements :

• On all browsers, there are font-sizes (like 20pixels) where the improvement by converting the postscript are absolutely radical. This will be crucial for your headers.
• Overall, IE10 is performing really good.
• In a small font-sizes, it is often better to stick with .ttf (or .woff with TrueType outlines), look at the 14px and smalleer fonts. They look horrible with postscript outlines.
• The previous point is not valid for every fonts. Good practice is to make your test to see how the font you want to use render in the diffrent sizes. And sometimes event to change the font you wanted to use because it renders poorely.
• Beyond 60px, chrome render both outlines the same way.
• On IE8 and less, .eot font will be used, and it could be awfull. But honestly … for people who do not make the effort to update their browser, it is already very nice of you to make an effort and not just display everything with Arial.