· Tech watch

Optimiser le rendu de @font-face : tout un programme !

Depuis quelques années, @font-face est devenu l’outil indispensable pour agrémenter une interface web de fontes exotiques.

Mais comment expliquer les différences de rendu, parfois considérables, d’un navigateur et d’un OS à l’autre ? Penchons-nous sur la question.

Introduction

Pour utiliser une jolie typo sur un site web, vous avez plusieurs solutions, la plus pérenne et la plus efficace étant @font-face.

Je ne vais pas couvrir la base du fonctionnement de @font-face : Typographisme, David Lemaitre et Goulven Champenois l’ont très bien fait. La suite de cet article partira donc du principe que vous connaissez tout ça et que vous avez envie d’aller plus loin.

Non, ce qui m’intéresse moi, c’est de vous présenter un peu plus en détails les différents formats de police, en particulier TTF, OTF et WOFF, de tenter de répondre à la question « Mais pourquoi mes fontes sont toutes cracra sous Windows », et de vous donner quelques astuces pour optimiser le rendus des polices @font-face.

@font-face, « une catastrophe industrielle » ?

Cet article est le fruit d’une réflexion qui a commencé avec cet article de Arnaud Martin, qui estimait que les polices @font-face fournies par Google Webfonts constituaient « une catastrophe industrielle » sous Windows XP et Windows 7.

Bien que l’expression soit forte, je comprends très bien sa réaction. En utilisant directement sur un site une typo fournie par Google Webfonts au moyen du petit code JavaScript fourni, on constate des problèmes d’affichage sous Internet Explorer en général, et sous Chrome en particulier.

Qu’Internet Explorer ne soit pas franchement un modèle en terme de qualité d’affichage de polices @font-face n’est pas un scoop ; mais que Chrome galère, c’est déjà plus surprenant.

La faute revient en partie à ClearType, sous Windows. ClearType est une technique mise au point par Microsoft qui, en théorie, permet d’obtenir une netteté des polices aussi nette sur un écran que sur une impression papier.

Disponible dès la première version de Windows XP, elle y est désactivée par défaut. En revanche, une version améliorée de ClearType est activée par défaut sous Windows Vista et Windows 7.

Dans le projet qu’il évoque, Arnaud Martin a utilisé une fonte fournie par Google Webfonts. Cependant, le problème qu’il a rencontré aurait pu concerner n’importe quelle autre fonte fournie par n’importe quel autre service.

La solution que le développeur proposait au début pour pallier le mauvais affichage de cette fonte dans un Google Chrome tournant sous Windows 7 consistait en plusieurs étapes :

  1. Tout d’abord, il convertissait la police TTF (TrueType) en format OTF (Opentype) ;
  2. Ensuite, dans la déclaration @font-face, il remplaçait l’appel au format TTF par le format OTF ;
  3. Enfin, il appelait le format OTF avant le format WOFF – point qu’il a lui-même invalidé depuis, à raison. Nous verrons pourquoi au cours de l’article.

Quand j’ai découvert cette méthode, j’étais enthousiaste. Soulagée de voir que quelqu’un ait pris le taureau par les cornes afin de trouver une solution, j’ai commencé à mettre cette solution en place sur quelques projets : je voyais effectivement une amélioration des fontes sous Chrome pour Windows !

Et puis, en en discutant avec d’autres développeurs et experts front-end, je me suis rendue compte que cette méthode n’était pas la bonne, en dépit de son apparente efficacité.

Il s’agit donc dans un premier temps de démontrer pourquoi cette solution est loin d’être idéale et, dans un second temps, de suggérer une autre méthode pour optimiser le rendu d’une fonte donnée dans la plupart des navigateurs et des systèmes d’exploitation.

Fausses bonnes idées

Fausse bonne idée nº1 : convertir une fonte TTF en OTF

Convertir un TTF en OTF, puis appeler l’OTF à la place du TTF dans une déclaration @font-face est inutile.

Pourquoi ? Tout simplement parce que TTF et OTF, ça revient peu ou prou à la même chose.

Stupeur et tremblements !

En effet, le format OTF (OpenType) n’est autre qu’une version améliorée du format TTF (TrueType).

Créé en 1996, OpenType est un format de fonte numérique vectorielle. Il a été développé à partir de TrueType SFNT, dont la structure de base a été conservée, mais à laquelle ont été ajoutées des fonctions typographiques inédites. OTF offre ainsi une grande richesse typographique, qui permet de gérer les exceptions et les particularités de tous les systèmes d’écriture du monde.

Ainsi, techniquement, OTF n’est qu’une sorte de « conteneur  » pour TTF, une évolution de TrueType, et pas un format complètement neuf sorti de nulle part. Je vous renvoie à l’excellent article de Wikipédia pour en savoir plus sur les caractéristiques techniques de OpenType.

Par rapport à TrueType, OpenType permet de gérer, par exemple, des ligatures et des glyphes alternatifs. Ce qui explique pourquoi le format OTF a rencontré un grand succès auprès des graphistes et des web designers, qui ont naturellement pris l’habitude de considérer que TTF était has been car moins complet.

On préférera raisonner de manière plus juste :

  • Le format OTF, apparu il y a 15 ans, offre plus de fonctionnalités typographiques que TTF. Une fonte au format OTF devrait normalement s’afficher correctement sur le web ;
  • Le format TTF, apparu quant à lui il y a plus de 30 ans, requiert de la prudence : il faut toujours tester une fonte qui n’est disponible qu’au format TTF, pour être sûr que le fichier est récent et de qualité.

Pour résumer : sur le web, on peut utiliser des polices OTF et TTF avec @font-face, mais il faut toujours les tester, en particulier lorsque la police n’est disponible qu’au format TTF.

Le caillou dans la chaussure, c’est que TypeKit a annoncé il y a un an appeler lui-même, parfois, le format PostScript d’OTF à la place du format TrueType dans des déclarations @font-face ! Ceci précisément pour améliorer le rendu de certaines fontes sous Windows. Néanmoins, cela ne concerne qu’une poignée de polices spécifiques. Cette méthode ne doit absolument pas être considéré comme une méthode générale à appliquer partout.

Il n’est pas toujours pertinent de remplacer le format TTF par le format OTF : cela dépend en partie de la vétusté du fichier de la police.

Nous allons voir dans un instant comment on peut déterminer l’âge du fichier d’une police. Mais avant ça, j’aimerais revenir un instant sur WOFF, un format assez mal connu et pourtant révolutionnaire.

Fausse bonne idée nº2 : faire l’impasse de WOFF

L’un des arguments souvent opposé à l’utilisation de @font-face sur un site en production est son impact sur les performances : en effet, un fichier TTF pèse facilement une centaine de kilo octets.

Pour peu que plusieurs polices @font-face soient utilisées sur le même site, c’est autant de fichiers que le navigateur de vos utilisateurs devra télécharger. 400, 500 kilo-octets de fontes, voire plus, est-ce bien raisonnable ? Non.

C’est là où le format WOFF intervient : convertir une police OTF ou TTF en WOFF permet de diminuer son poids de 40 à 70 %. En effet, WOFF est un format compressé, a contrario de OTF et TTF. La compression du format WOFF est donc particulièrement intéressante pour améliorer les performances de votre site, à plus forte raison si celui-ci utilise plusieurs fontes @font-face.

À noter qu’il est également possible de compresser des fontes OTF et TTF à l’aide de Gzip, côté serveur (cf. ces exemples).

Dans votre déclaration @font-face, il est donc absolument nécessaire d’appeler la police au format WOFF avant le format TTF ou OTF, pour s’assurer que les navigateurs qui comprennent le format WOFF le téléchargent en priorité, avant toutes les autres, plutôt que de les forcer à télécharger un fichier TTF ou OTF 40 à 70 % plus lourd.

Cerise sur le gâteau, WOFF (acronyme de Web Open Font Format) est un format ouvert, initié par Microsoft, Mozilla et Opera, et standardisé au sein du W3C. Compatible avec IE 9+, Firefox, Chrome, Safari 5.1+, Opera, iOS 5+, Opera Mobile 11+, WOFF a donc de l’interopérabilité dans les veines.

Pour les versions antérieures d’IE, pas de souci : on embarque bien la typo au format EOT dans la déclaration @font-face. Et pour les versions antérieures des autres navigateurs, pas de souci non plus : chaque navigateur ne comprenant pas le WOFF passera directement au fichier suivant (TTF ou OTF, selon votre déclaration @font-face).

Edit du 14 janvier 2013 : à noter que le format WOFF peut également contenir, de façon facultative, un bloc de meta-données au format XML contenant notamment les informations relatives aux droits d’auteurs de la police. Merci à Jean-François Porchez de me l’avoir signalé !

Convertir un TTF ou OTF en WOFF : ça passe ou ça casse

Maintenant, je vous imagine, avec votre fichier TTF ou votre fichier OTF, mais sans le format WOFF : vous souhaitez donc le convertir en WOFF. C’est une bonne démarche, qui plus est facile à réaliser avec FontSquirrel, mais cela demande de prendre des précautions :

  • Si le fichier OTF ou TTF est de bonne qualité, le fichier WOFF généré sera de bonne qualité ;
  • Si le fichier OTF ou TTF est de mauvaise qualité, le fichier WOFF sera de mauvaise qualité.

Mais comment définir si un fichier de police est « de qualité » ou « de mauvaise qualité » ? Tout dépend du format des glyphes contenus par la fonte.

Si la fonte contient des glyphes au format PostScript, le fichier est propre, le dessin des glyphes est de qualité. La compression en WOFF ne posera donc aucun problème : le fichier WOFF sera impeccable et bien compressé, parfaitement optimisé pour le web.

A contrario, si la fonte contient des glyphes dessinés au format TrueType historique, alors vous pourrez toujours tenter de compresser votre fichier en WOFF : celui-ci sera de mauvaise qualité.

Toute la question est maintenant de savoir comment déterminer la qualité d’un fichier typo récupéré sur Internet.

Comment déterminer la qualité d’une fonte pour le web ?

Un critère important : la date de création du fichier

Un critère important dans le choix d’une police pour le web est la date de création de son fichier, car cela donne un indice sur la technique utilisée à l’époque pour dessiner les glyphes.

Notez bien que c’est bien de la date de création du fichier dont on parle, et pas de la date de création de la police elle-même. La distinction est importante.

De nombreux fichiers typographiques sont inexploitables sur le web, car ils contiennent des glyphes dessinés au format TrueType historique, qui limite leurs possibilités typographiques. C’est pourquoi on peut faire le deuil de certaines fontes (en général celles dont le fichier a été créé il y a plus de dix ans) car elles nécessiteraient d’être complètement redessinées dans un fichier OTF flambant neuf, ce que peu d’entre nous sont capables de faire.

Les fontes dont le fichier TTF est ancien sont en général inexploitables sur le web, pour les raisons évoquées plus haut. Les transformer en OTF, WOFF ou EOT via un outil comme celui de FontSquirrel relève d’un entêtement maladif, et se soldera par une perte de temps inutile.

Pour résumer :

  • Si les glyphes de la fonte ont été dessinés il y a moins de dix ans, alors on peut émettre l’hypothèse qu’ils l’auront été directement au format PostScript, et que les capacités typographiques de la police, inhérentes à OpenType, seront bien exploitées. Si vous achetez une police chez Adobe, chez Linotype, ou dans n’importe quelle autre fonderie moderne, vous ne rencontrerez a priori pas de souci (mais cela ne vous exempt évidemment pas de la tester quand même ! On a eu des surprises…) ;
  • Si le fichier de la fonte est plus ancien que ça, attention : il est plus que probable qu’il contienne des glyphes au format TrueType, format qui en général ne fait pas bon ménage avec @font-face. Cherchez donc une version redessinée de cette fonte (ça existe, surtout pour les fontes « classiques »), ou bien partez carrément à la recherche d’une autre police, plus récente, qui ressemblera le plus possible à la fonte initiale.

Distinguer le bon grain de l’ivraie peut paraître difficile à cause des extensions des fichiers de polices : en effet, un fichier se terminant par l’extension TTF peut tout à fait contenir des glyphes au format PostScript ! Impossible de le savoir sans tester ; or, difficile d’acheter une police si on ne peut pas la tester au préalable !

La documentation de Microsoft Typography nous permet d’y voir plus clair. Ainsi, l’extension d’une fonte OpenType dépend du type de glyphes qu’elle contient.

  • Les fontes qui ne contiennent que des données CFF (c’est à dire aucun glyphe au format TrueType, et uniquement des glyphes au format PostScript) auront toujours une extension en OTF ;
  • Les fontes qui contiennent des glyphes au format TrueTrype pourront avoir soit une extension en OTF, soit une extension en TTF : cela s’explique par un souci de rétrocompatibilité de cette fonte avec des systèmes d’exploitation qui n’offrent pas de support d’OpenType, ou bien avec des versions précédentes de cette fonte.

À ce sujet, il est utile de noter que la fonderie Linotype indique, sur son site web, le format de chaque fonte qu’elle vend. C’est le cas par exemple sur la fiche produit de la Futura® Medium Oblique Pro :

  • « OT CFF » veut dire « OpenType CFF », garanti sans glyphes TrueType : cela correspond à PostScript. Cela veut donc dire, si vous m’avez suivie, que cette fonte est a priori optimisée pour @font-face ;
  • « OT TTF » correspond à TrueType : dans ce cas, il faut se méfier, prévoir de faire des tests et ne pas être trop surpris si la police ne s’affiche pas très bien sur le web ;
  • Pour certaines polices, il est également possible de récupérer des formats plus exotiques.

C’est une information très précieuse que nous fournit ici la fonderie. Si vous avez le choix, choisissez toujours une police dont les glyphes ont été dessinés au format PostScript. Cela vous garantit a priori que la fonte s’affichera bien sur le web.

Linotype peut se targuer de donner ce genre d’informations précises, car la typographie est son cœur de métier. C’est un niveau de qualité qui, certes, a un prix, mais qui vous permettra d’être plus serein quant à l’utilisation d’une de leurs fontes pour le web. On note d’ailleurs que les polices vendues au format OT CFF possèdent l’option « web font » ! Logique.

Vous noterez que j’utilise beaucoup le conditionnel et autres a priori : les fontes sur le web ne relèvent pas d’une science exacte. Il n’existe pas de règle universelle qui vous garantit que, oui, cette police-là s’affichera bien dans 100 % des navigateurs et des OS.

Même si telle ou telle fonderie vous indique que la typo que vous allez acheter contient des glyphes au format PostScript, cela n’est pas pour autant une assurance absolue que cette police s’affichera bien partout. Bien que cela soit frustrant, on ne peut que s’approcher du Graal en multipliant les vérifications d’usage et, bien sûr, les tests techniques.

Savoir qu’une police que vous allez acheter contient des glyphes au format PostScript, c’est plutôt bon signe. Maintenant, vous n’avez pas forcément le budget pour acheter une fonte « de luxe » pour chaque projet web auquel vous contribuez.

Qu’en est-il donc des formats des fontes distribuées gratuitement sur FontSquirrel, Google Webfonts et consorts ?

Il n’y a pas de mystère : dès que vous aurez téléchargé une des polices proposées sur ces sites, il va falloir la tester de manière intensive. En effet, ces fontes gratuites n’ont pas le même âge, ni le même niveau de qualité, et il est souvent impossible de dire quel format de glyphes elles contiennent !

Tester, tester, tester

On ne le dira jamais assez : @font-face exige que vous testiez, testiez et testiez encore le comportement de vos polices dans le plus de navigateurs et de systèmes d’exploitation possibles, afin d’éviter les mauvaises surprises.

Vous ne devez pas attendre la phase d’intégration d’un site pour tester vos fontes. Un test rigoureux doit être systématique dès la phase de design. En effet, il revient aux web designers de choisir la fonte qui convient à un projet donné, de juger si elle se comporte correctement dans tous les navigateurs, et, si tel n’est pas le cas, de choisir une fonte de remplacement. Seuls les graphistes auront l’œil pour s’assurer du bon rendu de la fonte.

Ce n’est donc pas aux développeurs front-end de s’en charger même si, faute de temps ou de moyens techniques, ce sont souvent eux qui s’y collent : un web designer n’a pas forcément une machine virtuelle Windows installée sur son Mac ; de la même façon, il peut être compliqué, s’il travaille sous Windows, de tester des typos sous Mac.

Détecter qu’une fonte s’affiche mal dans la dernière version de Google Chrome sous Windows 7 alors que le site est déjà en production démontre que la recette n’a pas été suffisamment rigoureuse. Si on travaille sous Mac, il faut impérativement tester le site développé sous Windows et sous Linux (les noms des OS étant ici complètement interchangeables).

Les nouveaux usages typographiques sur le web entraînent une mise à jour des processus de design, d’intégration et de recette.

La version française de Web Font Specimen est un outil simple et efficace qui vous permettra de vérifier simplement et rapidement l’affichage de vos fontes sur le web. L’essayer, c’est l’adopter.

À propos de la méthode de lissage dans Photoshop

Il n’y a pas que la qualité inhérente à la fonte qui rentre en jeu sur la perception du « bon » ou du « mauvais » affichage d’une police sur le web : le lissage des textes dans Photoshop sur les maquettes du site influe aussi sur notre jugement.

À choisir, définissez toujours la méthode de lissage « forte » dans Photoshop pour tous vos textes. Vous trouvez ça moche sur votre PSD ? Vous trouverez ça moche aussi lorsque le site sera en ligne. Cela peut donc être un indice pour éventuellement choisir une autre typo dès la phase de design. Cela concerne même les polices dites « web safe », qui sont installées sur la majorité des ordinateurs, comme Georgia, par exemple.

Sur l’exemple ci-dessous, on peut voir, sur l’image de gauche, le texte tel qu’il a été lissé en maquette. Tandis que la police Novecento, utilisée ici pour le titre, se comporte bien en @font-face (sauf sous IE), c’est étonnamment Georgia, utilisée pour le texte de labeur, qui détonne un peu par rapport à ce qui a été imaginé en maquette.

Georgia 15px sous Photoshop semble plus petite que Georgia 15px sous Firefox. Il n’y a que sous Internet Explorer 8 où elle s’affiche à peu près fidèlement à ce qui avait été prévu en maquette.

Comparaison de rendu des fontes Novecento (@font-face) et Georgia (web safe) sous différents navigateurs et systèmes d’exploitation
Maquette
Photoshop
Firefox 13
sous Mac OS Lion
Chrome 19
sous Windows XP
Internet Explorer 8
sous Windows XP

Le cas de Chrome sous Windows

Au début de cet article, j’évoquais le problème de l’affichage « catastrophique » d’une fonte récupérée sur Google Webfonts dans Chrome sous Windows 7.

C’est en effet un problème récurrent, et qui se produit avec différentes polices issues de Google Webfonts.

Prenons par exemple la fonte Righteous. Un rapide aperçu de la police dans la dernière version de Chrome sous Windows XP nous révèle déjà des problèmes :

Sous MacOS, toujours avec la dernière version de Chrome, on obtient un résultat beaucoup plus lissé :

Sous Internet Explorer 8, le paragraphe s’affiche aussi bien, en revanche, c’est le titre qui apparaît plus pixellisé (ici sans ClearType) :

La même configuration, cette fois avec ClearType, ne permet pas de voir une différence :

C’est quand même un coup dur pour Chrome sous Windows de voir qu’une fonte s’y affiche plus mal que sous Internet Explorer !

Pas de panique. Voici une méthode qui devrait largement améliorer le rendu d’une police récupérée sur Google Webfonts dans Chrome pour Windows :

  1. Au lieu d’appeler directement le code CSS ou JavaScript fourni par Google Webfonts sur votre site, récupérez le fichier TTF de la police :
  2. Utilisez le @font-face generator de FontSquirrel pour générer un kit @font-face avec votre fichier TTF. Ce n’est pas la peine de modifier les réglages par défaut, sauf si vous savez ce que vous faites (il est possible que je revienne sur les réglages FontSquirrel dans un prochain article).
  3. Récupérez votre kit @font-face, et téléchargez la version française de Web Font Specimen.
  4. En local, sur votre poste, modifiez WFS à l’aide de votre kit @font-face.
  5. Testez l’affichage de votre fonte dans un échantillon représentatif de navigateurs et d’OS, en priorité : Chrome pour Windows, mais aussi Internet Explorer 7 et 8.

J’ai fait le test avec Righteous, avant et après le passage à la moulinette de FontSquirrel. Avant la transformation du fichier TTF par FontSquirrel, voici ce que j’obtenais :

À partir de la taille 16, on observe une pixellisation excessive du texte, qui devient dès lors inutilisable.

Lorsque j’ai mis en place le kit @font-face de FontSquirrel, en revanche, le rendu de la fonte s’est considérablement amélioré :

Jusqu’à la taille 13, le texte est parfaitement lisible et lissé.

FontSquirrel a donc parfaitement réussi la compression du fichier TrueType au format WOFF, que Chrome utilise ici. Pourquoi ?

Tout simplement parce que Google compresse et allège les fontes qu’il distribue au maximum, afin d’en réduire le poids, sacrifiant sans doute des options de lissage (anti-aliasing, hinting, sub-pixel rendering).

Au contraire, FontSquirrel permet de rétablir ces options ; de là à savoir si leur rétablissement alourdit le poids de la fonte, il faudrait faire des tests avancés.

Très souvent, OpenType n’a pas besoin de toutes ces options pour afficher correctement le texte à l’écran, là où TrueType a plus de mal.

Mais c’est surtout le couple navigateur / système d’exploitation qui a son dernier mot en matière de rendu typographique. Au moment de l’interprétation de la page web et de ses éléments graphiques, le navigateur va récupérer la fonte, passer la main au moteur de rendu de l’OS, puis récupérer le résultat pour enfin l’afficher.

Chaque navigateur n’envoie pas forcément les mêmes informations au moteur de rendu de chaque OS, et ne récupère pas forcément les mêmes informations non plus. En outre, cela dépend de la qualité de la fonte !

Trois facteurs majeurs qui expliquent notamment une telle différence de rendu entre, d’une part, un Chrome sous MacOS et un Chrome sous Windows XP ou 7, et, d’autre part, un Chrome et un IE8 sous Windows XP.

Quoi qu’il en soit, vous ne trouverez jamais une fonte qui s’affiche parfaitement partout. Quand bien même, elle pèserait sans doute pas loin d’un mégaoctet ! C’est donc une utopie totalement inadaptée pour le web.

Il s’agit là encore, comme pour tous les aspects techniques du web, d’évaluer quelle est votre cible principale et de choisir vos fontes en conséquence.

De même, le choix d’une fonte n’a pas la même importance selon qu’elle est utilisée pour du texte de labeur ou pour de la titraille.

Si, malgré tous vos tests, la fonte que vous souhaitiez désespérément utiliser avec @font-face s’affiche toujours mal dans telle ou telle configuration, et que vous ne réussissez pas à trouver une police équivalente, la dernière option consiste à redessiner la fonte… si toutefois vous avez des talents (et des logiciels) de typographe.

Redessiner une fonte ancienne

Les fontes sont, à l’instar d’une œuvre artistique ou d’un logiciel, protégées par droit d’auteur : leur utilisation est soumise à l’acceptation d’une licence spécifique. On ne peut pas utiliser n’importe quelle fonte sur le web gratuitement. Il faut toujours lire sa licence pour savoir si son utilisation, en print ou sur le web, est gratuite. C’est une lapalissade de le dire, pourtant certains se font encore avoir !

Cependant, en France, l’article L. 123-1 du Code de la propriété intellectuelle stipule que les droits d’auteur expirent 70 ans après la mort de l’auteur. Cela signifie que tous les dessins des fontes créées avant 1942 sont libres de droit et peuvent donc exploités librement. Un typographe zêlé est donc parfaitement en droit d’en redessiner une et de publier cette nouvelle version. D’ailleurs, s’il s’agit d’une fonte connue, celle-ci aura sûrement déjà été redessinée. Renseignez-vous !

C’est par exemple le cas de la Garamond, qui ne désigne pas tant une fonte en particulier qu’un ensemble de fontes serif (à propos, l’histoire de cette police est passionnante). De nombreuses fonderies, dont Adobe, ont créé leur version de Garamond depuis 1900 : il en existe aujourd’hui plus d’une centaine ! Dans ce cas, il est facile d’utiliser une version moderne et optimisée de Garamond sur le web, bien que la fonte initiale ait été créée il y a près de cinq siècles.

À l’instar de Linotype, dont nous avons parlé précédemment, la plupart des sites qui vendent des fontes indiquent désormais si une fonte est optimisée pour le web ou pas (c’est le cas de MyFonts et de FontShop, notamment).

Cependant, il ne s’agit que d’étiquettes et d’arguments commerciaux, qui ne doivent pas aveugler votre conscience et vous faire zapper l’étape nécessaire des tests multi-navigateurs et multi-plateformes. Nous ne saurions que trop vous recommander, avant tout achat de fonte pour le web, de la tester sur le web avant de l’acheter.

Testez ! Oui, testez !

MyFonts a mis en place à cet effet une sorte de « fenêtre de prévisualisation » pour ses polices web. Cet outil permet d’avoir une première idée quant au rendu de la police dans tel navigateur et sous tel OS.

Mais cela ne remplace pas un bon vieux test manuel et personnel, histoire d’en avoir le cœur net. Vous vous voyez dire, vous, « Mais dans l’onglet “Webfont browser screenshot” de MyFonts, elle s’affichait bien ! » à votre client ? C’est bien ce qui me semblait.

Conclusion

Ici s’achève notre promenade sportive au pays des formats de fontes, des problèmes de rendus typographiques et des outils à notre disposition pour tester la compatibilité multi-navigateurs et multi-OS d’une police utilisée avec @font-face.

L’objectif était de vous présenter sommairement les formats courants des polices @font-face, et de faire un tour d’horizon sur l’impact que chacun d’entre eux peut avoir sur l’affichage web des fontes.

En particulier, pour pallier les problèmes récurrents de rendu @font-face sous Chrome pour Windows, une petite conversion du fichier .TTF récupéré sur Google Webfonts via le générateur @font-face de FontSquirrel permet en général de sauver les meubles. Ceci est également valable pour tous les fichies de typo récupérés sur des sites proposant des fontes gratuitement.

Cependant, cela sera inutile sur un fichier .TTF trop ancien.

La chose à retenir est la suivante : testez, testez, testez ! Mettez vos collègues et vos amis à contribution, surtout s’ils ont une configuration matérielle différente de la vôtre.

N’hésitez pas à nous faire part de vos retours d’expérience sur des problèmes similaires liés à @font-face en général, et à un couple navigateur / OS en particulier !

Ajouter un commentaire

19 commentaires

  1. Super article ! Petit précision pour les utilisateurs de Font Squirrel. Comme il faut placer l’appelle du fichier WOFF en premier, il faut changer l’ordre dans le fichier CSS généré par Font Squirrel (logique)

    Exemple :

    Code généré par Font Squirrel :

    @font-face {
        font-family: 'maFont';
        src: url('maFont.eot');
        src: url('maFont.eot?#iefix') format('embedded-opentype'),
             url('maFont.woff') format('woff'),
             url('maFont.ttf') format('truetype'),
             url('maFont.svg#maFont') format('svg');
        font-weight: normal;
        font-style: normal;
    }

    Nouveau code :

    @font-face {
        font-family: 'maFont';
        src: url('maFont.woff') format('woff');
        src: url('maFont.eot');
        src: url('maFont.eot?#iefix') format('embedded-opentype'),
             url('maFont.ttf') format('truetype'),
             url('maFont.svg#maFont') format('svg');
        font-weight: normal;
        font-style: normal;
    }

    Répondre

    1. Il n’y a aucun risque que les navigateurs supportant WOFF lisent et chargent le fichier de police au format EOT.

      Ce n’est donc pas la peine d’appeler le fichier WOFF avant le fichier EOT.

      En outre, le navigateur utilisera toujours la dernière source (src) qu’il comprend dans une déclaration @font-face. Ici, si j’applique ta méthode, Firefox ne télécharge même pas la WOFF, et télécharge le fichier TTF, ce que nous ne voulons pas, pour les raisons évoquées dans mon article.

      À éviter donc !

      Répondre

  2. Bon article, mais c’est quand même une lourde méthode. Google devrait proposer un paramètre pour améliorer le rendu (ou optimiser suivant la connexion/le média)…

    Au passage, le code fourni par Google Web Fonts n’est autre que du HTML, qui charge du CSS. Il n’y a aucun JS dans l’histoire… ;)

    Répondre

    1. En effet, Google propose par défaut la méthode CSS, mais il propose également une méthode @import et une méthode JS.

      J’ignore pourquoi je suis restée bloquée sur la méthode JS… Je vais mettre à jour mon article. Merci !

      Répondre

  3. Tanguy Martin

    Super article j’ai beaucoup appris en le lisant. Tu ne parles pas des fontes au format SVG, y-a-t-il une raison pour ça?

    Est-ce que de manière générale les fontes dispo sur FontSquirrel sont de meilleure qualité que sur Google WebFonts? Qu’en est-t-il de Typekit et Fonts.com? TypeKit par ailleurs permet de visualiser directement le rendu d’une fonte selon sa taille et selon différents OS et navigateurs avant de choisir, grace à l’onglet « Browser sample », ce qui est bien pratique.

    Tu notes que le format TTF est apparu il y a un peu plus d’une 30aine d’année, j’ai été cherché l’article de Wikipédia sur ce format, et son historique est bien détaillé je trouve alors je vais mettre le lien ici: http://en.wikipedia.org/wiki/TrueType

    Merci pour l’article et toutes ces astuces.

    Répondre

    1. Merci pour le lien ! Je n’ai rien de plus à ajouter par rapport à la réponse que t’a faite Jérémie.

      Répondre

  4. Mais c’est surtout le couple navigateur / système d’exploitation qui a son dernier mot en matière de rendu typographique.

    Exactement! Pour ça, je pixellise tous mes textes, et c’est font-family: sans-serif; pour tout le reste. Pas con, le type!

    Répondre

    1. Qu’entends-tu exactement par « je pixellise tous mes textes » ?

      Répondre

  5. Jérémie Patonnier

    @Tanguy

    Tu ne parles pas des fontes au format SVG, y-a-t-il une raison pour ça ?

    Le but de cette article était de rentré en profondeur dans les format TTF/OTF/WOFF qui sont aujourd’hui les plus courrant, les mieux supportés et les plus riches.

    J’adore personnellement les fontes SVG, mais elles souffrent de deux défauts qui les rendent quasiment inutilisables:

    1. Tous les navigateurs ne les supportent pas (IE et Firefox par exemple)
    2. Les navigateurs qui les supportent ne supportent qu’une toute petite partie de la spécification ce qui rend difficile un usage sérieux de ce type de fontes

    Et même si le support été total au niveau des navigateurs, ces fontes ne sont pas du tout adapté au texte HTML car elle ne disposent pas de toutes les subtilités d’aide au rendu (le hinting en particulier) dont disposent les fontes OTF.

    Est-ce que de manière générale les fontes dispo sur FontSquirrel sont de meilleure qualité que sur Google WebFonts ? Qu’en est-t-il de Typekit et Fonts.com ?

    La qualité global est équivalente, il faut voir au cas par cas.

    TypeKit par ailleurs permet de visualiser directement le rendu d’une fonte selon sa taille et selon différents OS et navigateurs avant de choisir, grace à l’onglet « Browser sample », ce qui est bien pratique.

    Oui, c’est vraie et, de manière général, TypeKit est très en avance sur ce genre de chose. Cependant, rien ne vaux un test en situation réel. Personnellement, j’ai tendance à conseiller de n’utiliser que des fontes que vous avez pu tester vous même avant. Acheter une fonte les yeux fermés, quelque soit la qualité de la fonderie reste toujours un parie un peu risqué.

    Répondre

  6. Tanguy Martin

    Super, merci pour ces précisions Jérémie.

    Répondre

  7. Emmanuel Clément

    Excellent article, et bien rédigé de surcroit.

    Mais comment définir si un fichier de police est « de qualité » ou « de mauvaise qualité » ? Tout dépend du format des glyphes contenus par la fonte. (…) Toute la question est maintenant de savoir comment déterminer la qualité d’un fichier typo récupéré sur Internet.

    Ces derniers temps je découvre l’éditeur de polices Fontforge.

    En éditant les glyphes d’un fichier TTF avec Fontforge, on peut vérifier si celles-ci sont tracées en vectoriel ou en bitmap (j’avoue que je n’ai pas encore rencontré de fonte bitmap pour l’instant avec ce logiciel).

    Pratique pour vérifier la qualité de la police. On peut ré-enregistrer la fonte avec de nouveaux paramètres, au format de son choix, etc.

    Un FLOSS manual sur les fontes libres fait une très bonne présentation de Fontforge.

    Répondre

  8. Curiosité : j’ai un client qui me dit que le rendu de certaines webfonts est mauvais sous Chrome sous Mac (alors qu’il est très bien sur Chrome PC/Firefox PC/MAC, etc.). Est-ce que vous avez un embryon de piste ou d’idée ?

    Sinon, merci beaucoup pour cet article, je le fais tourner :)

    Répondre

  9. Fabrice Theytaz

    @Marie Oui il faut absolument mettre le format WOFF en premier, en tout cas lors de l’utilisation de OTF à la place de TTF. Avec Firefox 23 sous Windows Vista je n’étais jamais parvenu à faire fonctionner ce foutu lissage de polices… jusqu’à aujourd’hui… Merci donc pour votre article et à @MatteoBZ pour son commentaire.

    Répondre

  10. Fabrice Theytaz

    Hum pas tout à faire sur de mon message précédent… Firefox n’a pas l’air de charger le WOFF (il devrait pourtant?) mais que l’OFT… Étrange tout ça…

    Répondre

  11. @Marie
    Es-tu sûre de toi concernant l’ordre de chargement des fontes (cf. ta réponse à @MatteoBZ) ?
    Si j’ai bien compris, tu affirmes que le dernier src déclaré prendra le pas sur les autres ?

    Selon le w3c « […] Its value is a prioritized, comma-separated list of external references or locally-installed font face names. When a font is needed the user agent iterates over the set of references listed, using the first one it can successfully activate. » (http://www.w3.org/TR/css3-fonts/#src-desc)

    Je suis par conséquent plutôt d’accord avec la proposition de @MatteoBZ

    Répondre

  12. Marie Guillaumet

    Bonjour Maslow,

    Non, tu as raison, je me suis emmêlé les pinceaux dans mon commentaire ! C’est bien entendu la première source que le navigateur comprend qui est utilisée. :)

    Petite parenthèse à ce sujet : bien que IE9+ comprennent le format EOT, ils ne l’utilisent pas et passent directement à WOFF à cause du format indiqué pour EOT : format(‘eot’).

    Si on remplaçait format(‘eot’) par format(’embedded-opentype’), alors là, oui, IE9+ utiliseraient la fonte au format EOT. (cf. cet article sur Fontspring)

    Mais nous ne le souhaitons pas, car EOT est un format de fichier typographique très pauvre ! Fin de la parenthèse.

    J’en reviens à ta question, à propos de l’éventualité de passer la déclaration WOFF avant la déclaration EOT.

    Le résultat sera simple : IE8 et inférieurs n’afficheront pas du tout la police font-face !

    En effet, outre le fait qu’IE8 et inférieurs ne supportent pas le format WOFF, IE souffre d’un bug de parsing qui le pousse à essayer de comprendre la deuxième déclaration src de la déclaration.

    Il va donc envoyer une requête HTTP vers : maFonte.woff)%20format(‘woff’),%20url(maFonte.eot[…] ! Ce qui ne peut qu’aboutir sur une 404.
    (Cf. cet article de Typographisme)

    Cela explique pourquoi on ajoute un « ? » à la fin de la source EOT, pour duper IE8 et inférieurs, qui interprètent ça comme une query string sans conséquence pour l’URL du fichier.

    Cela explique aussi pourquoi il faut bien appeler le fichier EOT en premier ; le format WOFF ne peut donc intervenir qu’en seconde position.

    En revanche, si ton projet ne supporte pas IE8 et moins, tu peux te passer du fichier EOT qui devient inutile, et appeler WOFF en premier dans ta déclaration font-face.

    J’espère que cela répond à tes interrogations :)

    Répondre

  13. Parfaitement !

    Merci beaucoup pour cet article et ces précisions ;)

    Répondre

  14. […] J’avais écrit un article approfondi sur font-face et ces problématiques-là, qui est encore d'actualité : Optimiser le rendu de @font-face : tout un programme ! […]

    Répondre

  15. […] Chrome : blog.clever-age.com/ Les problèmes de rendu font-face sous chrome et firefox, utiliser des contours […]

    Répondre

Répondre à Maslow Annuler la réponse

Votre adresse email ne sera pas publiée. Les champs obligatoires sont indiqués par un astérisque.

Vous pouvez utiliser les balises et attributs HTML suivants dans votre commentaire : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre>