Variabidouille

En mars 2021 j’ai participé à un workshop avec Gijs de Heij d’OSP autour des fontes variables. Le point de départ de ce workshop était un ensemble d’utilitaires créés/rassemblés par Gijs pour :

• convertir une fonte du format ttf en ttx (XML donc texte brut et donc modifiable facilement)
• transformer la fonte ttx en fonte ttx variable (dans le code ttx, rajouter une table de variations possibles)
• modifier cette table de variation pour créer une instance qui serait la fin d’un axe de variation ‘MVMT’
• re-convertir ce ttx customisé en ttf
• visualiser le résultat dans un navigateur
• pourvoir créer une animation de cette variation en fichiers svg, pour être diffusé grâce à un laser superpuissant

En ce moment je m’intéresse à “l’utilisation” du graphisme et aux outils, et comment je peux faire du graphisme qui sera “utilisé”, par qui/comment, et comment il pourra être réapproprié par les utilisateur·ices.

Ce qui m’a parlé dans ce workshop c’est :

• le fait que ce soit un outil
• le fait que ça ouvre des possibilités programmatiques de création de fontes/fontes variables (on peut agir sur les points de chaque glyphe automatiquement, même les points “hors-courbe”, les poignées de points Bézier)

Pour l’instant le code de Gijs est une collection de scripts en python/javascript et je voulais les rassembler en un processus de traitement unifié et continu. Par exemple, on va sur une page web, on importe une fonte, et la conversion/variabilisation/exportation/visualisation se fait plus ou moins sous la capot. Créer une interface à partir de laquelle on peut “variabliser” une police en suivant divers algorithmes (encore à construire).

C’est toujours quelque chose que j’aimerais faire, mais l’outil d’inspection/visualisation de Gijs a un potentiel pédagogique qui parle de comment sont faites les fontes, et comment fonctionnent les fontes variables. Maintenant je me dirige plutôt vers une sorte d’outil de “débuggage”/d’analyse où la variation crée par le script permettrait de démontrer ce qui se passe dans le tracé d’une lettre par un ordinateur (ou l’humain qui la dessine vectoriellement). Cet outil produirait aussi des formes typographiques complexes à prévoir “manuellement”, intéressantes graphiquement (j’espère) et propres au tracé de la fonte de départ.

• Wakamai Fondue (What Can My Font Do ?), un site qui permet de voir toutes les possibilités d’une fonte (et qui permet de tester les variations)
• opentype.js, qui permet d’accéder à la fonte et de la modifier en direct
• Un site fait par FontBureau, un gros morceau sur l’histoire/l’utilisation actuelle/future des fontes variables

En fait ce qui se passe dans le format ttx, c’est que toute la fonte est définie dans un fichier XML (fonctionnant avec un balisage ressemblant à de l’HTML). Il est composé de plusieurs “tables” qui définissent différentes paramètres de la fonte :

• <GlyphOrder>, qui donne l’ordre des glyphes
• <glyf>, qui définit la taille de la case dans lequel est dessiné chaque glyphe, ainsi que tous les points qui composent les contours qui composent le glyphe
• <fvar>, qui définit les axes de variation et leur paramètres
• <gvar>, qui définit les “deltas” (déplacements) qui s’opèrent sur les points définis dans <glyf>
• et bien d’autres choses

Ce que fait le script de Gijs, c’est rajouter une table fvar pour définir un axe MVMT et une table gvar à une fonte qui n’en possède pas, et que l’on peut ensuite modifier.

La nouvelle fonte ainsi produite peut être variée sur l’axe MVMT.

Tout ça c’est sympa, mais ce qui se passe plus précisément c’est que la création des points dans la table gvar et leur déplacement s’opère de manière itérative. C’est-à-dire que le premier point modifié est le point les plus en bas à gauche du A capitale (ou le premier glyphe défini dans la fonte) et le suivant est le prochain point dans le sens des aiguilles d’une montre (ou pas, ça dépend du sens du tracé défini lors de la fabrication de la fonte).

Dans l’ordre des tracés, les contrepoinçons sont dessinés en dernier, après les autres contours. Dans certains glyphes, les lettres sont dessinées en plusieurs morceaux : la traverse du A peut être un rectangle à part des autres fûts, et la panse du n à part du fût vertical par exemple.

Ces éléments propres au dessin de la fonte dans un logiciel peuvent être mis en avant par la variation créée par l’outil que j’aimerais bricoler. On se rend compte qu’une lettre est une série de points reliés par des tracés influencés par d’autres points de tension.

Pour être pédagogique, il faut savoir à qui on veut démontrer des trucs. Je pense que le plus intéressant est de s’adresser à des personnes qui ne s’y connaissent pas en typographie sans pour autant faire de la variabilité un truc fun qui sert à faire des animations cools sur le web.

Je pourrais me servir de la variabilité pour rendre visible des caractéristiques du dessin de caractères, comme par exemple l’ordre des points, les points de courbes de Bézier, le ductus d’un glyphe, la logique du contrepoinçon, la modularité dans la construction de certaines lettres…

En reprenant la base du code de Gijs, j’ai bidouillé quelques changements pour arriver à ça : Chaque slider permet de changer un paramètre différent : l’intensité de variation, la taille et la “profondeur”, c’est-à-dire le nombre de lignes topographiques qui montrent les étapes intermédiaires de la variation.

En voyant ça j’ai pensé à des sliders pour créer des personnages dans des jeu vidéo :

Et en parlant de personnages, ce qui m’a marqué personnellement quand j’ai commencé à m’intéresser à la typo c’est que chacune avait sa personnalité, sa connotation à transmettre. Mais je me suis dit que pour quelqu’un·e qui ne s’y connaît pas en typo, le dessin de caractères peut sembler bien inutile, et qu’au final c’est juste des lettres qui se ressemblent. On voit vite fait une distinction entre serif/sans-serif/mono/cursive et le reste est superflu. Alors comment montrer que chaque fonte induit une impression singulière ?

En tirant un peu par les cheveux, on peut voir un lien entre le dessin de caractères et le design de caractère (dans le sens de personnalité/personnage, character).

À partir de ça j’ai pensé à faire une interface web de création de personnage, où l’utilisateur·ice remplirait un formulaire avec le nom/taille/corpulence/trait de caractère/qualité etc. de son personnage. Chacune de ces informations pourrait être associée à une caractéristique typographique pour réaliser une fiche de personnage récapitulative mise en page automatiquement :

• taille = interligne
• corpulence = taille du corps (haha encore un jeu de mot)
• trait de caractère = choix de la police (ex : strict → Helvetica-like)
• qualité = algorithme de variablisation (ex : sait trouver plusieurs solution pour résoudre un problème → algorithme qui bouge les points de courbes, varie les chemins/tracés pour passer par les même points)

(par exemple)

On peut bien sûr imaginer plein d’autres paramètres.

Évidemment, on peut critiquer ces interfaces de création de personnages : les valeurs par défaut qui représentent souvent une norme dominante (homme cisgenre blanc), les limites assez réduites (corpulence maximum plutôt faible , hommes forcément très musclés…), la binarité de genre etc.

En utilisant plutôt des caractéristiques de personnalité j’évite une partie de ces problèmes, mais je dois faire attention à ne pas reproduire ces schémas.

J’ai aussi pensé aux questionnaires de personnalité dans les magazines un peu nuls. Des genres de QCM où chaque réponse est représentée par un symbole (rond/étoile/cœur/triangle…). En comptant le nombre de symboles qu’on a obtenu à la fin on a le droit à un petit texte “personnalisé” qui décrit notre personnalité. Dans ce type de questionnaires les réponses sont tellement orientées que le résultat devient évident. C’est aussi un endroit où les réponses sont très catégoriques et stéréotypées.

L’idée ça serait d’utiliser des codes visuels de ces deux champs pour mon interface web.

Pour commencer je me suis servi d’une base de travail sur un générateur d'affiche en PHP/javascript que j’avais fait il y a un moment (un de mes premiers projets avec du code).

Dans les interfaces de création de personnages dans les jeux vidéos, on voit en direct ce qu’on est en train de faire et le résultat que ça va donner. La logique du générateur de base que j’ai pour l’instant c’est de récolter les informations dans un premier temps puis de traiter tout ça pour créer l’affiche dans un second temps. On ne se rend pas compte des paramètres pris en compte pour la mise en page.

Pour ce projet j’aimerais que ce soit un peu plus clair (pour rester dans la logique de pédagogie), qu’on puisse essayer des trucs en ayant une idée de ce qui se passe. Par exemple, un des choix de l’utilisateur·ice est la couleur préférée du personnage. Ma première idée serait que cette couleur serve de fond coloré pour la fiche de personnage générée. J’ai ajouté un peu de javascript pour que lorsque l’on sélectionne la couleur l’arrière-plan change dynamiquement, pour que l’on sente que ce paramètre aura un impact. L’objectif est de faire la même chose pour tous les paramètres.

Pour que tout fonctionne comme prévu j’ai écrit 2 pages : une page de formulaire et une page de traitement/affichage. Puisque dans le formulaire la fonte est déterminée par le choix du caractère et l’algorithme de variation par le choix de la qualité, je me retrouve avec plein de possibilités de combinaison des deux.

Je me retrouve avec un choix :

• soit je prépare à l’avance toute les combinaisons possibles (avantage de temps de chargement mais désavantage de devoir tout préparer manuellement avant et de recommencer à chaque modification)
• soit je les génère sur demande et je les stocke au cas où elles resservent plus tard. (avantage de souplesse mais désavantage de plus de boulot de préparation)

Je pense partir plutôt sur la deuxième option, qui me laisse introduire des paramètres dans la variation des fontes qui sont gérés par d’autres questions du formulaire (intensité de la variation, dimension aléatoire…).

Voilà la base du script bash qui me permet de faire la transformation en une seule étape :

#!/bin/bash
 
INPUT_FILE=$1
filename="${INPUT_FILE%.*}"
output="${2%.*}"
OUTPUT_FILE=$2
 
ttx $INPUT_FILE
python3 make-gvar-table.py $filename.ttx ${output}_temp.ttx
python3 modify-gvar-table.py ${output}_temp.ttx $output.ttx
ttx $output.ttx
 
# Remove temporary ttx files
rm $filename.ttx
rm ${output}_temp.ttx

Le problème c’est que pour l’instant il ne marche qu’avec un fichier ttf en entrée (et en sortie aussi). L’utilitaire ttx permet aussi de convertir un fichier otf en ttx, mais c’est un format différent donc les tables en XML ne sont pas les mêmes et pas forcément dans le même ordre. Les scripts python ne fonctionnent donc plus, puisqu’ils se basent notamment sur la table <glyf> qui n’existe pas dans les fontes au format otf.

Pour l’instant j’ai plusieurs fontes libres dans un dossier (chacune associée à un trait de caractère). Je les téléchargées sur internet donc elles sont dans des formats différents (otf/ttf/woff/woff2). J’ai à un nouveau le même type de choix : soit je convertit tout à la main soit je rajoute dans le script bash des conditions pour tout convertir en ttf avant de tout repasser en ttx. Pour l’instant pour des raisons de simplicité je vais tout convertir à la main, à voir plus tard si je veux étoffer le projet.