Quand les fonts embarquées ne rendent pas aussi bien qu’on l’espérait.

[Edit] : Depuis que Chrome et Firefox ont changé le moteur de rendu de leurs fonts, cet article est moins pertinent. Mais toujours intéressant.

Le problème

La propriété font-face, c’est une authentique antiquité dans le monde du web. Microsoft l’a introduit il y a 15 ans -en octobre 1997- dans la version 4.0 son navigateur grâce à l’implémentation d’un nouveau moteur de rendu : trident.

Elle n’a rencontré que peu de succès à son lancement pour tout un tas de raisons techniques. À mon avis, la raison majeure de cet insuccès était le poids d’une font intégrée. À une époque où dépasser les 100 ko pour une page était considéré comme une hérésie… ajouter 50 ko de font était hors de propos.

Aujourd’hui, les autres navigateurs l’ont implémenté -d’une bien meilleure façon que la première version- ; les débits internet ont considérablement augmenté et c’est devenu une pratique très en vogue. Les designers ont donc logiquement commencé à s’intéresser de près au rendu des fonts dans les différents navigateurs… et c’est vite devenu un vrai casse-tête. Notamment pour les grand corps (18+) ; c’est de ceux-là dont je vais vous parler.

Un excellent article dans smashing magazine explique le pourquoi du comment des problèmes de rendu. Chaque navigateur utilise un moteur de rastérisation (conversion des fonts en pixels) différent, et qui n’est pas forcément le même en fonction du type de contours utilisés pour le dessin de la font. Ces contour peuvent être de type TrueType (TT-webfonts) ou OpenType/CFF (PS-webfonts). Voir cet article sur le blog d’Adobe qui explique la différence.

En conclusion, pour mac os, on ne se préoccupera pas du rendu puisque tous les navigateurs utilisent quartz pour rendre les fonts. Sous Windows, ce n’est pas le cas. Chaque navigateur a choisi un moteur de rendu. Ci-dessous un tableau tiré de l’article qui récapitule les moteurs de rastérisation en fonction du navigateur et du type de font.

Globalement, DirectWrite fonctionne bien pour les deux types de fonts ; mais le résultat n’est pas exactement le même. CGI ClearType ne gère que l’antialisating vertical et pas l’antialisating horizontal et a donc un rendu très différent de GDI grayscale.

Le résultat peut être assez dramatique en fonction de la font. Ci-après, des captures d’écran du rendu de l’écran d’accueil de google webfont dans différents navigateurs :

Je ne suis pas fan du rendu des fonts web classiques -ici de l’Arial- sous ie10 ; mais pour le reste, c’est bien meilleur que dans chrome et firefox. On peut d’ailleurs se demander comment il est possible que google ne fasse pas quelque chose pour améliorer le rendu de ses fonts dans son propre navigateur.

Le souci, ce n’est pas le type de rendu dans l’absolu, c’est d’avoir le choix. Un rendu soft et très antialiasé dès qu’on passe les 16 points de corps et un rendu plus net en dessous.

La solution

Comme typekit l’explique dans cet article, la solution à ce problème est de proposer des fonts avec des contours postscript pour firefox et chrome.

/!\ Si vous avez déjà lu quelque part d’utiliser des fonts en svg pour chrome, oubliez ça tout de suite ; le rendu est bon lettre par lettre, mais vous risquez un grand nombre de bug dans un paragraphe.

Commencez par télécharger une font de chez google web font. J’ai pris la première (Sanchez). Vous obtennez le fichier Sanchez-Regular.ttf. La première étape, c’est de le convertir en .otf avec des contours PS via un logiciel comme TransType. Pour vous assurer que la conversion a bien été effectuée correctement, il vous suffit d’ouvrir le fichier avec l’aperçu des polices de Windows. Ici une capture d’écran des version .ttf et .otf.

Normalement, vous devriez voir une différence très marquée entre les deux. La version avec les contours TrueType est pixélisée ; alors que la version avec les contours postscript est bien antialiasée. Dans le header de la police, le type de contour est spécifié.

Allez ensuite sur le générateur de kit font-face de fontsquirrel pour se créer un kit. Pour obtenir les version eot et svg de la font. Une fois le kit créé, on a les fichiers en .eot, .woff, .svg et .ttf. Ce générateur ne gère pas les contours PS, pour le fichier woff, on en utilisera un autre.

• Le fichier svg vous servira pour les navigateur sous iOs.
• Le fichier .eot vous servira pour les anciennes versions de ie.
• Le fichier woff est construit à partir de contours TrueType, jetez-le.
• Le fichier .ttf ne vous servira à rien, jetez le.

(Les fichiers à jeter peuvent aussi ne pas être généré en cochant les bonnes cases dans le générateur de font squirrel)

Il va maintenant falloir générer un fichier woff avec des contours postscript. Pour cela, vous allez utiliser un petit utilitaire : sfnt2woff. Téléchargez la version précompilée pour windows. Vous obtiendrez un petit .exe sur lequel il suffira de drag&droper le fichier au format .otf pour qu’un fichier .woff soit généré.

Résultat et intégration

Vous êtes donc paré pour l’intégration et disposez des fichiers suivants :

• une font format .otf => vient de la conversion du fichier .ttf téléchargé initialement via un logiciel comme TransType.
• une font au format .woff => vient de la conversion du fichier .otf via l’outil sfnt2woff.
• une font au format svg => vient du générateur de fontsquirrel à partir du fichier .otf.
• une font au format .eot => vient du générateur de fontsquirrel à partir du fichier .otf.

Récapitulatif des cibles de chaque font :

Vous pouvez maintenant passer à l’intégration de votre font dans le 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;
}

L’ordre est très important. En résumé, le navigateur va prendre la première chose qu’il parvient à interpréter. Vous pouvez maintenant utiliser ‘sanchezregular’ pour la propriété font-family de votre CSS.

A : pour ie 6 et moins
B : pour ie 7 et 8
C : pour les navigateurs récents
D : pour les navigateurs plus anciens gérant l’otf
E : pour iOs

Conclusion

Voici une animation qui montre la différence entre le rendu obtenu avec la font en .ttf et la font en woff avec des contours postscript (Opera se comporte comme firefox) :

On peut retenir plusieurs éléments :

• Sur tous les navigateurs, il y a des corps (comme le corps 20) où l’amélioration apportée par une conversion de la font en postscript est absolument radicale
• Au global, c’est ie10 qui s’en sort le mieux.
• En petit corps, il vaut mieux rester en .ttf (ou en woff avec contours trueType) ; voir le corps 14 et moins dont les rendus sont affreux en contours postscript.
• Attention, la remarque précédente n’est pas forcément valable en fonction de la font que vous utilisez. La bonne pratique, c’est de tester votre font pour voir ce qu’elle donne dans les deux types de contours en fonction du corps.
• Au delà du corps 60, chrome applique un antialias aux contours trueType similaire à celui qu’il appliques aux contours postscript.
• Sur ie8 et moins, ça sera des fonts en .eot et ce ne sera pas forcément terrible en fonction de la font. Mais honnêtement… pour les gens qui ne font pas l’effort de mettre leur navigateur à jour, on est déjà bien gentil de faire un effort et de ne pas tout leur mettre en Arial.