Convertir OTF en WOFF

Les cahiers des charges survivent aux raisons qui les ont fait écrire. Un document de guidelines de marque de 2015, une page d’exigences d’assets d’une plateforme, ou la checklist d’un développeur copiée d’un tutoriel va lister .woff parce que c’était la bonne réponse au moment où cela a été écrit, et personne n’y est revenu depuis.

Discuter en vaut rarement l’heure. Produisez le WOFF, produisez le WOFF2 à côté, et notez dans la livraison que c’est ce second fichier que les navigateurs utiliseront réellement. Cela satisfait le cahier des charges et laisse le destinataire mieux loti que ce que le cahier des charges aurait prévu.

Un changement de conteneur, et rien d’autre. La table CFF qui porte les tracés cubiques, la table de correspondance de caractères, les métriques, le crénage et chaque feature OpenType que le dessinateur a définie sont recopiés tels quels puis compressés. Aucun glyphe n’est redessiné, aucune feature n’est abandonnée, et le fichier peut être déballé plus tard pour récupérer l’OTF.

Ce dernier point a une conséquence qui mérite d’être connue avant une livraison : un WOFF n’est pas un emballage protecteur. C’est une copie compressée de la police, et toute personne qui la reçoit peut la reconvertir en fichier de bureau installable en quelques secondes. Tout ce qui s’applique à l’OTF s’applique au WOFF.

Un bon paquet est petit et sans ambiguïté : un fichier par graisse et par style, nommé de telle façon que la graisse soit lisible sans rien ouvrir, et un fichier texte ou un extrait contenant les règles @font-face qui vont avec. Le développeur ne devrait pas avoir à deviner quel fichier est le semibold italique.

N’incluez que les graisses que le design utilise. Remettre un dossier de dix-huit coupes parce que la famille en a dix-huit, c’est comment un site finit par en charger quatre par accident, et cela rend l’exposition à la licence plus large que le projet n’en a besoin.

La plupart des licences commerciales de polices nomment le licencié et n’autorisent pas le transfert. Un studio qui a acheté une licence de bureau et qui remet les fichiers convertis à un client n’a en général pas fait du client un licencié — il a fait deux parties utilisant une seule licence, et l’exposition retombe en général sur celui qui a signé.

Les voies praticables sont les voies ordinaires : le client achète la licence web en son propre nom et vous produisez ou recevez les fichiers, ou le projet utilise une famille sous licence libre. Les polices sous SIL Open Font License peuvent être converties, sous-ensembées, redistribuées et auto-hébergées, à condition de ne pas être vendues seules et de ne pas réutiliser des noms réservés, ce qui explique pourquoi tant de travaux clients se rabattent discrètement dessus.

Le navigateur choisit un fichier en utilisant la graisse et le style déclarés dans la règle @font-face, pas le nom de fichier. Mais c’est le nom de fichier qu’un humain lit trois mois plus tard, donc les deux doivent s’accorder — marque-600-italic.woff à côté d’une règle déclarant font-weight 600 et font-style italic ne laisse rien à interpréter.

La défaillance que cela évite est le faux gras. Une famille livrée avec un seul fichier regular, puis utilisée en bold, produit un bold écrasé par le navigateur, visiblement moins bon que la vraie coupe. C’est le défaut le plus courant d’un paquet de polices livré et c’est entièrement une erreur d’empaquetage plutôt qu’une erreur de conversion.

WOFF2 est lu par tous les navigateurs actuels et fait environ trente pour cent de moins que le WOFF de la même police. Quoi que dise le cahier des charges, c’est ce fichier que le site doit servir, et le produire coûte une conversion de plus.

Ne les empilez pas dans la même règle @font-face comme paire de repli. Le navigateur prend la première source qu’il comprend, qui sera toujours le WOFF2, et le WOFF devient un fichier que personne ne télécharge et que personne ne met à jour — une copie périmée de la police qui attend sur le serveur qu’un outil réordonne la règle. Livrez les deux, et dites lequel est à utiliser.

Un OTF à une seule graisse avec un jeu de caractères Latin étendu complet commence couramment quelque part dans les basses centaines de kilooctets. L’envelopper en WOFF en retire une fraction utile ; l’envelopper en WOFF2 en retire encore environ un tiers.

Aucun de ces deux chiffres n’est là où se trouve le vrai gain. Sous-enser la police aux caractères que le site va utiliser bat les deux d’une marge importante — une police de bureau de 300 Ko ramenée au Latin de base et convertie en WOFF2 atterrit couramment autour de 25 Ko. Si le poids de page est dans le brief, le sous-ensimage fait partie du livrable, et il se fait avant la conversion plutôt qu’après.

C’est le piège qui attrape spécifiquement les studios. Votre machine a l’OTF installé, donc quand un navigateur ne peut pas charger le WOFF il retombe sur la famille installée localement du même nom et la page est parfaite. Le client, qui n’a pas cette police, voit de l’Arial.

Une fenêtre de navigation privée n’aide pas — la police est installée au niveau du système d’exploitation, pas dans le navigateur. Vérifiez sur une seconde machine, sur un téléphone, ou en donnant temporairement à la famille @font-face un nom qu’aucune police installée n’utilise. Dix secondes de cela supprime la manière la plus gênante dont une livraison de police peut rater.

Déposez le dossier entier plutôt qu’un fichier à la fois. Jusqu’à 100 polices se convertissent en une seule passe et reviennent en un ZIP avec les noms préservés, ce qui est la forme que veut une livraison. Recommencez une fois pour WOFF2 et le paquet est fait.

Le travail tourne sur notre serveur, parce que fontTools n’a pas de build navigateur. Chaque fichier voyage par une connexion chiffrée, est converti dans un environnement isolé, et le répertoire de travail est supprimé à la fin du travail. Le quota gratuit est de 100 conversions serveur par jour avec un plafond de 25 Mo par fichier — une famille complète et son second format tiennent dans une fraction de cela.