Font-face rendering problem in chrome and firefox, use postscript outlines


[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.

rasterisation engine for different browsers and outlines

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 google webfont in different browsers :

aspect of google webfont home page in different broswers

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.

The solution

As Typekit explain it in 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 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.

font ttf et otf dans windows

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 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 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 : 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 :

Summary of each file target :

font format support for each browser

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


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) :

difference rendu postscript et ttf contours

You can remenber several elements :