Essai : typographie pour le Ouaibe

@import url(http://fonts.googleapis.com/css?family=Lobster&subset=latin);

Un peu trop… trop. En tout cas pour un grand châpo, cette police Google Lobster. Mais pour un essai, cela passera…

@import url(http://fonts.googleapis.com/css?family=Vollkorn&subset=latin);

h1 { font-family: ‘Vollkorn’, arial, serif; }

Il y a diverses méthodes pour faire en sorte que le visitorat de votre site voit votre texte, non pas exactement tel que vous l’avez composé, mais au moins avec la police que vous avez choisie.

Une méthode très, très simple, mais qu’on réservera, pour du texte courant, à des haïkus ou de courts poèmes, par exemple, consiste à créer tout simplement une image : le texte est pixellisé. Attention, selon la force de corps et divers paramètres, le texte peut apparaître « crénelé ». Les contours des « glyphes » apparaissent « en escalier ».

L’autre méthode est plus limitative. Vous devez choisir des polices que « tout le monde » possède, installées sur son propre ordinateur. Ou des polices, qui telles l’Arial, ont de « parfaites » équivalentes installées « en dur » chez le visiteur, le destinataire. Ainsi, la plupart des non-spécialistes sont incapables de distinguer une Arial d’une Helvetica. En gros, lorsque vous utilisiez, naguère, une police Arial de votre IBM-PC compatible, l’utilisateur d’un MacIntosh affichait le même texte en ayant recours à une police Helvetica correspondante.

Assez tôt, les développeurs et les fonderies ont voulu contourner ces limitations. Ils ont créé des polices « optimisées pour l’affichage sur les écrans » (leurs glyphes ont des caractéristiques d’ouverture, d’axe, &c., améliorant leur lisibilité), et cherché à les « incorporer » dans les fichiers HTLM. Cela impliquait qu’en tâche de fond, sans même sans rendre compte, le destinataire importe entièrement la police ou du moins tous les caractères utilisés (rendus par des glyphes correspondants). Pour ce faire, sa participation était requise. Il devait installer un module additionnel, un « greffon », une fois pour toutes. Ce module assure que l’importation de la police soit suivie de son rendu, de son affichage à l’écran. Deux inconvénients : comme les fournisseurs d’accès Internet ne se préoccupaient guère de ces problèmes, ils n’assuraient pas la promotion de cette méthode. Partant, des utilisateurs peu au fait de l’informatique hésitaient à installer ces modules. De plus, parfois, la police était « corrompue » lors du téléchargement ou le module ne parvenait pas à interpréter la police. C’était donc une police dite « système » (installée par le système d’exploitation de l’ordinateur distant) qui s’affichait, se substituant à la police temporairement téléchargée.

Deux techniques principales de ce type ont été développées. Weft, en liaison avec les développeurs de Microsoft, tout d’abord. Photofont, avec ceux du FontLab Group, une société de création de programmes et logiciels pour créer des polices de caractères. Weft, tout comme Photofont, permet d’utiliser ses propres polices classiques (s’affichant en noir ou dans une couleur prédéfinie). Photofont va plus loin en permettant de créer des polices « en couleurs » ou de transformer des visuels, représentant des glyphes, en « polices ». Ainsi, on peut créer des polices bi ou tricolores, « photographier » des caractères (par exemple former des lettres avec des chiffons, transformer l’ensemble de ces images en police). Depuis, le FontLab Group a complètement changé sa méthode. Il a recours à la technologie Adobe Flash, soit pour incorporer des polices Photofont, soit pour incorporer des polices d’un autre format. Cela pourra évoluer, notamment si, comme on lui en prête l’intention, Microsoft ferait l’acquisition d’Adobe. Des normes XML autres pourraient être implémentées. Mais, là, cela dépasse mes actuelles compétences (et même mes aptitudes).

Les fortes bandes passantes, les forts débits des flux rendus possibles par l’abandon des modems au profit de consoles ADSL ou câble ont permis aux fonderies d’envisager une toute autre méthode. Les polices du choix des créateurs de pages se situent sur un serveur distant. Quand le créateur du texte le compose, il utilise une police installée sur son ordinateur. Cela lui assure une visibilité « telle vue, telle rendue » (wysiwig) : ce qu’il voit sur son écran sera reproduit (imprimé ou affiché) à l’identique. Cependant, ce n’est pas la police dont il dispose en local qui sera « servie » au destinataire, mais la même, localisée sur le serveur d’une fonderie ou d’un partenaire. L’inconvénient est que ce service à un coût, même si on peut penser que des groupements utilisant des polices libres de droits d’auteur vont créer de tels services : les polices sont des logiciels, et le mouvement du « logiciel libre » pourrait appliquer cette technique.

C’est ce que fait la société privée Google. Elle met gratuitement à dispositions des Internautes un choix de polices d’accès libre et gratuit, et des scripts ou commandes d’encodage permettant d’importer les mêmes polices depuis ses serveurs. Bien sûr, l’utilisateur peut télécharger son choix de polices afin d’afficher le texte sur son propre écran à l’identique de ce que le destinataire visualisera. Mais ce n’est pas une obligation. Il peut composer dans n’importe quelle police, mais s’il a incorporé le code d’importation d’une police Google, c’est cette police qui sera servie aux visiteurs de son site. Pour le moment, le choix de Google est assez limité. Tant en polices qu’en « graisses » (les texteurs ou les logiciels de retouche d’images, par exemple, peuvent créer du « faux italique » ou du « faux gras », mais un graphiste digne de ce nom à recours à des fichiers de polices distincts : l’un pour la police normale, un autre pour l’italique, la demi-grasse, la grasse, &c.).