Présentation
Le token‑space font compiler transforme une police de caractères et un tokenizer LLM en une police où chaque token occupe exactement la même largeur, soit 3 em. L’outil fonctionne entièrement dans le navigateur : l’utilisateur charge une police (TTF, OTF, WOFF ou WOFF2) et sélectionne ou téléverse un tokenizer (DeepSeek V4.1, OpenAI ctok v4.8, Kimi K3, Llama 3, etc.). Le résultat est un fichier TTF autonome contenant les règles de mise en forme du tokenizer, sans script supplémentaire.
Fonctionnement et architecture
Le processus de compilation repose sur une recherche de segmentation à coût minimal limitée à 256 étapes par composant indépendant. Cette contrainte exclut le cadre du message et se base sur une normalisation approximative du tokenizer ctok, ce qui reproduit les découpages de Claude sans garantie d’exactitude. Chaque entrée du vocabulaire est intégrée dans la police ; les caractères de format invisibles peuvent toutefois perturber les limites de mots, et les versions v3/v4.7 présentent des erreurs de normalisation d’espaces initiaux.
Le compilateur associe le nom du tokenizer au nom de la police de base (Inter, Roboto, SF Mono, JetBrains Mono, etc.). En mode « lite », disponible uniquement pour les BPE Fonts et Gemini, la police générée est plus petite et la compilation est plus rapide, mais le rendu du texte peut devenir légèrement plus lent. La police finale inclut, en option, des polices de secours : Noto Emoji (monochrome) et Mutant Standard (couleur) sous licence CC BY‑NC‑SA 4.0. Ces glyphes de secours sont incorporés dans le même fichier TTF, garantissant une couverture de base même si la police d’origine ne possède pas certains caractères.
Analyse des limites et implications
Le principal avantage réside dans la visualisation uniforme des tokens, utile pour le debugging ou l’étude de la tokenisation. Cependant, la dépendance aux « browser shaping runs » signifie que les limites de tokens peuvent varier selon le moteur de rendu (Chrome, Firefox, etc.) et les balises de formatage. La prise en charge des scripts complexes (arabes, hindi, etc.) reste restreinte : le compilateur ne gère pas les ligatures ou les formes contextuelles avancées, ce qui peut entraîner des ruptures de mots ou des espaces inattendus.
La largeur maximale d’espacement supplémentaire est plafonnée à 0,5 em, et la valeur par défaut est zéro. Cette contrainte assure que chaque token occupe exactement 3 em, mais empêche toute personnalisation fine de l’interlettrage. De plus, la compilation de tokenizers volumineux (plusieurs millions d’entrées) peut prendre plusieurs minutes, ce qui limite l’usage en temps réel.
Enfin, l’intégration dans des clients de messagerie (Discord via le thème Vesktop, Slack via un userscript) repose sur l’identification d’un ID d’utilisateur ou d’un nom d’affichage. Le système ne modifie pas le texte, il ne fait qu’appliquer la police compilée. Si le thème ou le script n’est pas correctement chargé, le rendu reste celui de la police par défaut, rendant le processus sensible aux mises à jour du client.
