Polices de caractères personnalisées sur le web : quelles solutions ?

Les polices de caractères sur le web

Un bon choix typographique est essentiel lorsque l’on s’intéresse à l’esthétisme général d’un document – mais cet article ne va pas vous aider dans ce choix, parce que sur le web, il est plutôt réduit.

En effet, les polices de caractères ont la particularité d’être liées au système d’exploitation de l’internaute et non pas à son navigateur ou au site qu’il visite, tout au plus le site a son mot à dire sur la police souhaitée, mais sans être sûr que ce choix sera disponible dans l’OS du visiteur.

Par exemple si vous spécifiez que le texte de votre page web doit être affiché en Comic Sans MS (personne n’est parfait) mais que votre internaute n’a pas cette police sur son ordinateur (ce qui est vrai si il n’est pas sous Windows), c’est une autre police qui est utilisée ! Pour avoir un design cohérent sur la majorité des configurations, les créatifs sont donc contraints de se limiter à certaines polices, connues pour être disponibles ou ayant des alternatives [[http://www.fonttester.com/help/list_of_web_safe_fonts.html]][[http://en.wikipedia.org/wiki/Web_safe_fonts]].

Avoir un média aussi riche qu’internet et devoir se limiter à une vingtaine de choix typographiques est très frustrant, alors des petits malins ont imaginé des solutions pour utiliser n’importe quelle police sur votre page web. Elles ont toutes leurs avantages et leurs inconvénients et c’est ce que je vais m’efforcer de décrire dans ce document.

Le problème : Licence d’utilisation des polices

Une des principales raisons pour lesquelles les polices de caractères embarquées sur le web n’ont pas encore percé est d’ordre légal : faire un lien vers une police True Type (via la propriété CSS font-face, que nous allons étudier) revient à rendre possible le vol de celle-ci. En effet n’importe quel utilisateur averti saura retrouver ce lien dans les CSS et télécharger la police, sans l’avoir achetée.

Les licences d’utilisation de la majorité des polices de caractères professionnelles sont très restrictives sur cet aspect, elles sont souvent limitées à un ordinateur et il est interdit de les embarquer en pièce jointe d’un document. C’est le cas par exemple des fontes de [Hoefler & Frere-Jones->http://www.typography.com], dont le contrat d’utilisateur final interdit l’utilisation de @font-face. Cette limitation parait excessive à de nombreux travailleurs du web, à l’heure où on trouve des polices gratuites partout sur internet – mais elles sont loin des fontes professionnelles, véritables oeuvres d’art et de conception, s’échangeant à plusieurs centaines de dollars.

Il n’y a pas de solution miracle, la plus prometteuse est Embedded Open Type (EOT), un format propriétaire de Microsoft qui permet d’inclure des DRM et de compresser les polices avant de les linker dans son CSS. Viennent ensuite les techniques de remplacement dynamique (on prend le texte, et on le transforme en image / rendu vectoriel…) comme sIFR, et pour finir, certaines initiatives de création de licences dédiées au partage libre – comme la GNU with Font Exception ou la Open Font Licence.

Les solutions disponibles

En règle générale, pour faire un titre <h2> (ça pourrait être pour un texte, voire tout un site) avec une police dont on sait très bien qu’elle ne sera pas rendue pareil sur l’ordinateur du voisin, on met ce dernier en dur comme un titre normal et on le remplace par une image en CSS (Fahrner Image Replacement technique et son amélioration (plus accessible)), c’est une bonne solution mais elle n’est ni souple, ni applicable à du texte dynamique.

Petit tour d’horizon de ce qui se fait sur le web :

Remplacement de texte par une image

C’est aujourd’hui la technique la plus utilisée, pour remplacer un titre en particulier. Elle consiste à cacher un texte, et à appliquer une image en background via CSS.

<h1 id="websiteTitle"> Mon site web </h2>

#websiteTitle <em>text-indent : -9000px ; background : url(websitetitle.gif) ; </em>

Elle est simple, robuste mais présente quelques inconvénients comme le fait qu’on ne puisse plus sélectionner le texte ! De plus si l’image n’existe pas ou si le visiteur souhaite ne pas l’afficher, le texte est invisible. Et enfin cette technique manque cruellement de souplesse, il faut générer les images à la main.

Font-face

Comme précisé en introduction, il est possible via CSS d’utiliser une police de caractère personnalisée avec la propriété font-face, introduite en CSS2 (la spécification a ensuite disparu en CSS2.1 pour réapparaître en CSS3 avec le module Web Fonts).

Très simple à utiliser, il suffit de donner un nom (qu’on utilisera ensuite dans notre font-family) et une url vers un fichier de police.

@font-face <em>font-family:Garamond ; src:url(garamond.ttf) format("truetype") ; </em>

Un vrai jeu d’enfant ! Et là vous vous demandez pourquoi on ne l’utilise pas ? La réponse est simple, elle n’est supportée que par Safari 3.2, Chrome 2, Opera 10 et Firefox 3.5 et pose de sérieux problèmes de licence (la police doit autoriser le font-linking ce qui est très rare, je vous conseille ce site dédié aux polices libres) et de poids (les glyphes inutiles ne sont pas retirés, le fichier peut donc être lourd).

Font-face avec EOT

Il s’agit de la même syntaxe (excepté pour le format() qui n’est plus nécessaire) mais pas des mêmes problèmes. Supporté uniquement Internet Explorer, et ce depuis la version 4 (1997) ! Oui le sujet de la police de caractère sur le web date de la grande guerre des navigateurs, en 1997 Netscape 4 supportait aussi la typographie embarquée.

@font-face <em>font-family : Garamond ; src : url(garamond.eot) ; </em>

Il n’y a que le format de la police qui change, EOT correspond à Embedded Open Type. Il a été introduit par Microsoft dans Internet Explorer 4, avec l’outil WEFT (Web Embedding Fonts Tool) pour convertir des polices TrueType en OpenType (comme Flash, WEFT ne permet pas d’embarquer des polices dont la licence interdit ce type d’utilisation).

Le format inclut des protections contre la copie – ainsi le fichier de police contient une liste de domaines sur lesquels il peut-être utilisé. La police est aussi compressée et ne comporte que les glyphes dont on a besoin. Au final il faut une dll propriétaire pour la lire. Ce format n’est donc supporté par personne d’autre (Microsoft l’a récemment soumis au W3C). Il s’agit d’une solution intéressante dans le sens où les polices sont protégées contre la copie, et seul CSS est utilisé. Mais il faudra quelques années avant de pouvoir l’utiliser et personne ne sait si la « protection » des fichiers tiendra !

Facelift (FLIR)

Le FLIR (Facelift image replacement) reprend le principe du remplacement d’image mais en beaucoup plus souple. C’est ici un script Javascript et un PHP qui vont se charger de remplacer les textes et de générer les images correspondantes (dans le cas de FLIR c’est PHP qui est utilisé, mais c’est adaptable à tous les langages côté serveur).

Les couleurs et les tailles définies dans le CSS sont automatiquement reportées au script PHP qui génèrera donc l’image correspondante.
Les inconvénients sont plus ou moins les mêmes, il devient impossible de sélectionner le texte, on génère une charge supplémentaire côté serveur, et quelques extensions comme GD et FreeType sont nécessaires.
Le temps de chargement des images peut poser problème (même avec le cache, les images sont chargées en PHP pour être affichées) – ce temps s’ajoute aux remplacements via Javascript et au temps de chargement global.

Ce genre de solution nécessite d’avoir le fichier de police sur son serveur, mais seul PHP a besoin d’avoir accès en lecture dessus, il est donc possible d’éviter le pillage, mais certaines fontes nécessitent l’achat d’une licence supplémentaire pour être disposées sur un serveur.

TypeFace / cufón

Il s’agit là de la nouvelle génération de script de remplacement de texte à la volée en Canvas / SVG / VML via Javascript.
Ces technologies permettent de dessiner des graphiques vectoriels, et donc potentiellement des polices.

TypeFace est composé de deux éléments : un module Perl pour convertir les polices et un Javascript pour dessiner les lettres. En fait les polices ne sont pas placées sur le serveur telles quelles, avec l’outil de conversion on choisit les glyphes que l’on souhaite utiliser, et on reçoit un fichier contenant les coordonnées utiles au dessin vectoriel. Ce fichier de police intermédiaire pourrait être récupéré par un utilisateur mais il ne pourrait l’exploiter qu’avec TypeFace.

Comme vous vous en doutez, plus il y a de glyphes, plus le fichier de police est lourd. Pour une police simple on atteint facilement les 210ko, auxquels s’ajoutent le javascript de TypeFace (16ko). On a ensuite le temps de calcul nécessaire à Javascript pour dessiner les polices. Sur nos navigateurs récents, toujours plus rapides avec Javascript, ce temps est relativement acceptable (entre 500 et 1200ms sous Safari 4) mais qu’en est il pour les navigateurs plus anciens ?

On retrouve aussi l’impossibilité de sélectionner du texte (en fait, pour les navigateurs utilisant Canvas, le texte se sélectionne bien mais ne se surligne pas…) ou de l’agrandir avec les fonctions du navigateur.

Dans le même genre on a aussi cufón qui est un peu plus abouti mais qui a exactement les mêmes défauts. Il est à noter que cufón s’en sort beaucoup mieux en termes de compression de police et de rapidité d’exécution.

sIFR 3

La dernière solution que je vais présenter est sIFR : scalable Inman Flash Replacement. Comme son nom l’indique, on remplace le texte par du Flash. Un peu de CSS, de Javascript et un fichier Flash sont nécessaires pour utiliser des polices personnalisées.
Aucun code côté serveur n’est exécuté, le fichier de police n’est utilisé qu’à l’export du clip flash, et le texte généré se comporte comme du texte : on peut le sélectionner, le copier, le changer dynamiquement sans recharger le clip Flash. Il n’en reste pas moins que l’utilisation de Flash engendre de nombreux problèmes : consommation CPU, liens en flash (ce qui ne permet pas d’ouvrir dans un nouvel onglet par exemple, comme on pourrait le faire avec un vrai lien), et le texte qui n’est pas vraiment comme les autres textes de la page et n’est donc pas considéré par le navigateur (un CTRL+A sur une page contenant un texte en flash ne sélectionnera que le texte normal).

La technologie Flash permet de choisir les glyphes à exporter, ce qui permet de gagner de nombreux kilo octets, comme pour cufón, typeface et EOT.

sIFR 2, sorti en 2005 était loin d’être parfait, il était très courant de devoir bidouiller à cause d’une taille de police mal détectée, et ne fonctionnait pas avec le full zoom de nos navigateurs récents. sIFR 3 (actuellement en beta) règle tous ces problèmes et fonctionne de façon générale beaucoup mieux que son prédécesseur sur l’ensemble des navigateurs. Un javascript de debug est aussi disponible, bien pratique !

Cette solution a quelques émules, comme sIFR Lite et jQuery sIFR. Je ne vais cependant pas les décrire ici car elles sont toutes les deux basées sur sIFR 2, et ont tendance à simplifier le code original de sIFR (en réintroduisant des incompatibilités). Je vous conseille fortement d’utiliser la dernière nightly de sIFR 3.
Il est aussi à noter que le texte remplacé par sIFR 3 beta 2 est lu par JAWS 10 avec IE7 et Firefox 3, GW Micro Window-Eyes 7 avec IE7 et Firefox 3 et Apple VoiceOver avec les derniers WebKit. Il s’agit donc d’une solution supportée et reconnue par l’industrie.

Critères de choix

– Poids total : possibilité de n’inclure que les glyphes utiles, librairie javascript, poids des fichiers…
– Lourdeur : consommation CPU, exécution côté client, temps d’affichage
– Compatibilité : fonctionne sur la grande majorité des navigateurs graphiques du marché
– Sélection du texte : la sélection et la copie du texte est-elle possible ?
– Accessibilité : agrandir le texte (ou fonction full-zoom du navigateur supportée), utilisation de plugin, support par les lecteurs d’écrans
– Optimisation pour le référencement : comment les robots des moteurs de recherche interprètent le texte ? Vous pouvez remarquer qu’aucune des solutions présentées n’est néfaste au référencement, en effet il ne s’agit que de méthodes de remplacement : le robot du moteur de recherche n’a ni Javascript, ni CSS, il lira donc le texte original
– Légalité : respecte, ou tente de respecter les licences d’utilisation des polices commerciales
– Liens : possibilité de faire des liens sur le texte remplacé

Solution / Conclusion

A l’heure actuelle, le choix est donc plutôt simple à faire. La seule solution largement compatible, respectant les licences d’utilisation des polices commerciales (ou en tout cas pas trop simple à contourner), étant dynamique et pas trop lourde pour le poste client est sIFR 3. Cufón se pose aussi comme une solution de choix, bien qu’encore jeune elle évolue très bien et est régulièrement mise à jour, contrairement à sIFR dont le développement est complètement bloqué depuis octobre 2008 (Mark Wubben parle cela dit de mettre en place le code de sIFR sur GitHub, permettant ainsi à de nombreux développeurs de participer à son l’évolution).

On peut aussi se demander si la guerre des navigateurs est vraiment finie, à l’heure actuelle, aucun des trois grands éditeurs de navigateur (Mozilla, Apple et Opera) ne planche sur le format EOT. Microsoft de son côté refuse d’implémenter le Font Linking car il n’est pas dans l’intérêt des vendeurs de polices de caractères. Toute la difficulté est là : comment concilier les besoins des créateurs de sites web avec les restrictions de l’industrie typographique.

Glossaire

– Font linking : on met l’url d’un fichier de police que le navigateur télécharge et utilise (font-face en CSS, c’est du font-linking)
– Font embedding : on ne link pas le fichier de police original, il est transformé dans un format intermédiaire.
– Glyphe : un caractère ou un accent dans une police de caractère.

Sources

– [http://www.fontembedding.com/fonts-and-the-web/->http://www.fontembedding.com/fonts-and-the-web/]
– [http://www.slideshare.net/novemberborn/geek-meet-web-typography-and-sifr-3->http://www.slideshare.net/novemberborn/geek-meet-web-typography-and-sifr-3]
– [http://msdn.microsoft.com/en-us/library/ms533034.aspx->http://msdn.microsoft.com/en-us/library/ms533034.aspx]
– [http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/#webfonts->http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/#webfonts]
– http://a.deveria.com/caniuse/#agents=All&cats=All&eras=All&statuses=All
– [http://ajaxian.com/archives/facing-up-to-fonts->http://ajaxian.com/archives/facing-up-to-fonts]
– [http://ajaxian.com/archives/cufon-custom-font-embedding-with-svgvml->http://ajaxian.com/archives/cufon-custom-font-embedding-with-svgvml]

Et si la typographie vous intéresse je vous conseille aussi cette série d’articles de SitePoint faisant le point sur les principes de base, ainsi que ce récent article sur hacks.mozilla.org.