Sans en faire toute une histoire, à tout le moins laisser une trace…
Pour temps zéro, j’ai souhaité améliorer le rendu du texte des articles, au moment où la revue connaît un rafraîchissement majeur. Une des variables plus délicates à contrôler : la typo. Plus encore, je voulais dépasser la dualité espace/espace insécable pour favoriser un meilleur alignement des ponctuations. En typographie conventionnelle, on utilise des espaces fines (quart de cadratin au lieu de demi-cadratin ou, en numérique, cinquième au lieu de quart de cadratin) entre les mots et certaines ponctuations – guillemets, ponctuations hautes… Qu’en est-il en numérique ? C’est chose généralement négligée (euphémisme, quand on constate que même les insécables sont peu mobilisées, avec toutes ces ponctuations qui sont abandonnées en début ou fin de ligne, quelle engeance).
Quelques recherches me conduisent à un caractère Unicode inventé, surprise, pour la langue mongole (!) : l’espace fine insécable (ou pour les proches amis : U+202F ou, en décimale html, & #8239;). Petit test dans une page web beta : ça fonctionne chouettement.
Prochaine étape : trouver à faire digérer le code dans Lodel. Solution : un filtre php basé sur des expressions régulières. Fonctionne parfaitement (merci Dave, dieu des expressions régulières).
Après… ça se gâte. Le rendu est inconstant. Des machines avec mêmes versions de navigateurs rendent ou échappent les fines insécables. Pourtant c’est assez stable d’un navigateur à l’autre sur une même bécane. Hum… Après moult tests, le coupable s’appelle : police de caractères. J’accuse d’abord des versions différentes de polices d’un ordinateur à l’autre. Mais en fait, c’est plus pointu. Dans ma définition css, j’ai la séquence
font-family: ‘Georgia’, ‘Times’, ‘Times New Roman’, serif;
Je finis par comprendre que Georgia ne supporte pas la fine insécable. Par cascade, c’est Times New Roman qui prend la relève… enfin pas toujours. Times n’a pas de fine insécable, serif générique non plus. Et les Times New Roman, c’est comme le chocolat, il y en a une variété incroyable, selon son mode d’installation (système, Adobe, MS, etc.).
Quelques tests plus tard, j’identifie deux possibilités pour gérer le truc.
1. Recourir à une autre police déjà mobilisée par la page – une police web
Dans mon css, pour les titres, j’appelle une police web (une police g00gle en l’occurrence : Open Sans). Vérification faite : elle supporte les fines insécables, yé. Alors on met dans la cascade et c’est réglé ? Pas si simple… J’appelle la police par une entrée de la balise <head> :
<link
href=’http://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,400,300,600&subset=latin,latin-ext’
rel=’stylesheet’
type=’text/css’
/>
Ensuite, si j’ai une entrée css qui dit < font-family: ‘Open Sans’; >, ça passe bien. Mais ça ne passe pas si ce n’est pas le premier terme d’une cascade… alors que la logique de la situation, c’est qu’Open Sans vienne à la rescousse uniquement si une police antérieure ne gère pas le caractère demandé.
Deuxième recours : une twist css3, à savoir remplacer uniquement et spécifiquement le caractère problématique par une autre police. Il s’agit d’utiliser @font-face en entrée de css et de convoquer une règle : unicode-range. Une merveille de puissance de gestion. Démo et exemple de code ici. Le pire, c’est que ça fonctionne… mais à certaines conditions.
D’abord, la façon, encore une fois, d’appeler la police. Des polices locales, passe toujours (voir plus bas). Mais des polices web ? Le bordel. Pas moyen de convoquer le lien fait dans l’entête de la page, la police n’est pas reconnue. On peut forcer ce lien en remâchant la référence à la police (merci, oh grand web, mais j’ai perdu où/comment faire) :
src: local(‘Open Sans’), local(‘OpenSans’), url(http://themes.googleusercontent.com/static/fonts/opensans/v6/u-WUoqrET9fUeobQW7jkRbO3LdcAZYWl9Si6vvxL-qU.woff) format(‘woff’);
Mais ça ne fonctionne pas plus. Autre solution : télécharger la police en local, sur le serveur, et y référer :
@font-face {
font-family: ‘test’;
src: url(‘OpenSans-Regular.ttf’) format(‘truetype’);
}
Yé, ça fonctionne… ! Et on peut même faire une cascade. Mais… deux problèmes : A. si on fait de la belle ouvrage, comme dit l’autre, il faut une série de formats de polices pour satisfaire les navigateurs (voir notamment ici). Quelle galère. B. Ben Firefox, il n’aime pas les @font-face – pas plus qu’Opera d’ailleurs. J’oubliais de dire : il faut, pour que la règle unicode-range soit appliquée, que cette police soit appelée en premier dans la cascade (c’est ce à quoi j’en suis venu par différents tests). La règle fait que ça ne s’applique qu’à la plage de caractères déterminée, les autres prennent la police suivante. Mais avec Firefox/Opera, qui ne digèrent pas la règle unicode-range, l’effet est qu’ils appliquent uniformément la première police de la cascade, et donc pas la bonne. Zutre. Et tant pis pour @font-face, pas assez supporté.
2. Recourir à une autre police locale.
Par dépit (avec l’incertitude des polices stockées sur les ordis de nos bons lecteurs), j’explore cette avenue. Ça semble facile. Après essais/erreurs, je découvre que, parmi les plus courantes, Arial, Helvetica, Verdana et Times New Roman supportent ma fine insécable. Je découvre également que sur Firefox (Mac, récent), on s’en moque des polices, puisque la fine insécable est toujours au rendez-vous…
Mais la vie concrète m’apprend que rien n’est jamais simple. En fait, sur les cas problématiques observés (d’autres apparaîtront sûrement…), il n’y a que Helvetica qui permette de bien gérer, pff. Donc il faut absolument mettre cette police en fin de cascade (après serif) pour assurer l’affichage des insécables. Solution trouvée, au prix de bien des sueurs.
Pour l’instant, ça fonctionne. Il resterait à tester pour l’ensemble des navigateurs, d’âges variés… Il y aura sûrement des situations où on échappera le contrôle. Au moins, le caractère n’affiche simplement pas (le code décimal reste silencieux). Et surtout il faudra vérifier, pour les copains bidouilleurs (merci aux idées générées sur twitter la semaine dernière), si ça passe sur les liseuses, de façon à améliorer l’expérience de lecture en contexte numérique. Amenez-en des défis.
_______
*** Addenda : Internet Explorer de version antérieure à 9, sans grand étonnement, présente des carrés au lieu des fines insécables. Considérant que ces versions d’IE ne représentent que 6% des visites depuis le début de 2013, une simple note d’excuse suffira…
(photo : « Blokbookovok », Gleb Kachaev, licence CC)
