Outils de polices

La plupart des auteurs ne touchent jamais directement à un fichier .vf. Mais dès que l’on construit ou branche des polices, trois outils puissants deviennent nécessaires : la police virtuelle qui relie une police logique à des polices réelles, le JFM (Japanese Font Metric) qui décrit les largeurs de glyphes CJK et l’espacement de la ponctuation, et les outils de tables de glyphes qui montrent ce qu’une police contient réellement. Cette page traite de ces utilitaires de bas niveau destinés aux développeurs de polices et aux utilisateurs avancés.

Polices virtuelles — une police logique mappée sur des polices réelles

Une police virtuelle (.vf) est une couche qui mappe la police logique unique vue par TeX sur des glyphes réels et des opérations de composition de bas niveau. Pour reprendre les mots de la TeX FAQ, les polices virtuelles sont « a means of collecting bits and pieces together to make the glyphs of a font », ces morceaux provenant d’autres polices, de filets et de commandes de composition avec des informations de positionnement. Cela permet de remapper l’ordre des caractères, de combiner plusieurs polices en une seule, de simuler des petites capitales ou de regrouper les morceaux d’une police mathématique en une seule fonte.

Le mécanisme partage le travail en deux. TeX lui-même n’a besoin que des dimensions — largeur, hauteur, profondeur — qu’il lit dans le fichier compagnon .tfm (TeX Font Metric). La manière dont chaque glyphe est *réellement dessiné* — quel glyphe de quelle police réelle, décalé de combien — se trouve dans le .vf, et c’est le pilote DVI qui le lit (dvips, dvipdfmx). Une police virtuelle est donc toujours une paire : un .tfm plus un .vf. TeX positionne tout à partir du .tfm ; le pilote développe le .vf et verse le résultat dans les polices réelles.

Comme le .vf binaire n’est pas destiné aux humains, il existe une forme textuelle lisible, le .vpl (Virtual Property List). Écrit comme une « property list » imbriquée, il est pratique pour décrire et inspecter à la main les détails d’une police. Deux programmes convertissent entre les deux formes, et tous deux sont fournis par toute distribution TeX (vptovf et vftovp, issus des outils fontware) :

• vptovf — .vpl (texte) → .vf + .tfm (binaire). Transforme une description de police virtuelle écrite ou modifiée à la main dans la forme utilisable par TeX et le pilote.
• vftovp — .vf + .tfm (binaire) → .vpl (texte). Convertit une police virtuelle existante en forme lisible afin de contrôler ou modifier son contenu.

L’ordre des arguments vaut la peine d’être mémorisé. vftovp prend police virtuelle, métrique, sortie ; vptovf prend description, police virtuelle, métrique. Les extensions peuvent être omises dans les deux cas : .vf / .tfm / .vpl sont ajoutées pour vous. Pour démonter une police virtuelle existante, par exemple :

# 仮想フォントを人間可読の VPL に戻して中身を見る
# Turn a virtual font back into a readable VPL to inspect it
vftovp font.vf font.tfm font.vpl

# 編集後、VPL から .vf と .tfm を作り直す
# After editing, rebuild the .vf and .tfm from the VPL
vptovf font.vpl font.vf font.tfm

Placez le .tfm obtenu sous .../fonts/tfm/<supplier>/ et le .vf sous .../fonts/vf/<supplier>/ dans l’arbre texmf, rafraîchissez la base des noms de fichiers avec mktexlsr, puis vous pourrez les localiser avec kpsewhich font.vf. Pour le travail moderne de génération de polices virtuelles à partir de polices PostScript, il est plus courant d’utiliser fontinst que d’écrire un .vpl à la main. En pratique, une police virtuelle est plutôt quelque chose que l’on lit et ajuste finement depuis la sortie de tels outils, plutôt qu’un objet que l’on écrit de zéro.

JFM — Japanese Font Metric

La composition japonaise a besoin de ce qu’un .tfm occidental ne peut pas fournir. Les kanji et kana reposent par défaut dans une boîte carrée (pleine chasse), et l’espace entre eux n’est pas l’espace inter-mots du texte occidental ; les blancs s’ouvrent ou se ferment seulement autour de la ponctuation (parenthèses et signes d’arrêt). La structure qui porte cela est le JFM (Japanese Font Metric). pTeX et upTeX utilisent un fichier JFM binaire proche d’un .tfm ; LuaTeX-ja décrit le même rôle sous forme de table Lua.

La principale différence avec une TFM occidentale est qu’un JFM regroupe les caractères en « character classes ». Comme le précise le manuel LuaTeX-ja, toutes les longueurs d’un JFM sont des nombres flottants en unités de taille de dessin, ancrés sur zw (pleine chasse) et zh (pleine hauteur, height + depth) ; chaque classe porte ensuite ses propres width, height, depth et italic (correction italique). La classe 0 existe toujours et contient la grande majorité des caractères japonais, ceux qui ne relèvent d’aucune autre classe. La ponctuation et les éléments similaires vont dans des classes séparées, et une table de glue/kern à insérer entre une classe et une autre produit l’espacement autour des signes d’arrêt et des parenthèses.

Dans la famille pTeX, le JAglue — l’espace inséré entre deux caractères japonais, et entre un caractère japonais et du texte occidental — est ajouté automatiquement à la composition. Le JFM fixe l’écart entre les classes ; entre caractères japonais non classés, le kanjiskip par défaut est utilisé, et à une frontière japonais/occidental, xkanjiskip. Ce dernier, avec le *kinsoku* (les règles interdisant certains caractères au début ou à la fin d’une ligne), est central dans l’aspect de la composition japonaise. Un fichier JFM LuaTeX-ja est un script Lua qui effectue un seul appel à luatexja.jfont.define_jfm{ ... }, avec un squelette comme celui-ci :

-- LuaTeX-ja の JFM（抜粋）。寸法はすべてデザインサイズ単位
-- A LuaTeX-ja JFM (excerpt); all lengths are in design-size units
luatexja.jfont.define_jfm {
  version = 3,
  dir = 'yoko',          -- 横組み / horizontal
  zw = 1.0, zh = 1.0,     -- 全角の幅・高さ / full-width, full-height
  [0] = {                -- 文字クラス 0：大多数の漢字・仮名 / class 0: most kanji & kana
    chars = { '漢' },
    width = 1.0, height = 0.88, depth = 0.12, italic = 0.0,
  },
  [1] = {                -- 句点など別クラス / a class for stops, etc.
    chars = { '。', '、' },
    width = 0.5, height = 0.88, depth = 0.12, italic = 0.0,
  },
}

LuaTeX-ja fournit des JFM standard pour différents besoins. jfm-ujis.lua est le standard, fondé sur la métrique upnmlminr-h.tfm utilisée dans upTeX (la plupart des caractères sont carrés) ; jfm-jis.lua correspond à jis.tfm, largement utilisé dans pTeX (les caractères tendent à devenir des rectangles horizontaux) ; jfm-min.lua correspond au min10.tfm par défaut de pTeX. Dans une définition de police, on en choisit un avec jfm=, comme dans \jfont\F=HaranoAjiMincho-Regular:jfm=ujis. Les JFM binaires de la famille pTeX, quant à eux, se convertissent vers et depuis le texte avec ppltotf et ptftopl, les équivalents japonais de pltotf et tftopl pour les pl/tfm occidentaux.

Lister le contenu d’une police — fonttable et nfssfont

Pour voir quels glyphes une police contient réellement, on imprime une table de glyphes (table de police). Le moyen simple depuis un document est le paquet fonttable, dont la commande centrale \fonttable{<font>} compose un tableau de tous les glyphes de la police nommée. L’argument est le nom de la police, plus précisément de son .tfm : cmr10 pour Computer Modern Roman, pzdr pour Zapf Dingbats, etc.

\documentclass{article}
\usepackage{fonttable}
\begin{document}
% フォント名（.tfm）を渡すと全字形の表が出る
% Pass a font (.tfm) name to get a table of every glyph
\fonttable{cmr10}

% NFSS の 4 属性で指定する版（エンコーディング/ファミリ/シリーズ/シェイプ）
% The NFSS-attribute version (encoding/family/series/shape)
\xfonttable{T1}{cmr}{m}{n}
\end{document}

Pour spécifier par les quatre attributs NFSS, utilisez \xfonttable{<encoding>}{<family>}{<series>}{<shape>} (par exemple \xfonttable{T1}{cmr}{m}{n}). Vous pouvez réduire la plage de la table à des blocs de 16 glyphes avec \fontrange{<low>}{<high>}, jusqu’à un maximum de 256 glyphes. Et \fonttext{<font>} compose un texte d’exemple dans la police plutôt qu’une grille de glyphes, ce qui aide à juger son apparence réelle.

Ce fonttable est une remise en paquet des outils classiques fournis avec TeX, nfssfont.tex et testfont.tex (une grande partie du code du paquet est une version modifiée de nfssfont.tex, et ses commandes de test de glyphes réimplémentent le testfont.tex de Knuth). Les outils classiques fonctionnent *interactivement* : on lance tex nfssfont, on saisit un nom de police (comme cmr10), on utilise \table pour imprimer la table, \init pour passer à une autre police, et \bye pour terminer.

# 古典的な対話ツール：起動 → フォント名 → \table → \bye
# The classic interactive tool: launch, name the font, \table, \bye
tex nfssfont
# Name of font to test = cmr10
# *\table
# *\bye

Dans le même ordre d’idées, pour consigner l’identité de la police courante, \showfont affiche ses cinq attributs NFSS : encoding, family, series, shape et size. Pour tracer le comportement de chargement des polices lui-même, le paquet tracefnt est utile. Enfin, pour savoir ce qui est installé sur le système et d’où les fichiers sont lus, les points de départ sont updmap, qui gère les maps de polices, et kpsewhich, qui trouve l’emplacement réel d’un fichier (p. ex. kpsewhich cmr10.tfm).