Web2Cest une collection intégrée de programmes relatifs à TeX, c.-à-d. TeX lui-même, METAFONT, MetaPost, BIBTeX, etc. C’est le cœur de TeX Live.
Un peu d’histoire : la première implémentation a été réalisée par Tomas Rokicki qui, en 1987, a développé un premier système TeX-to-C en adaptant les change files pour Unix (travail de Howard Trickey et Pavel Curtis principalement). Tim Morgan assura la maintenance du système, dont le nom fut remplacé durant cette période par Web-to-C. En 1990, Karl Berry reprit le travail, assisté par des dizaines de contributeurs, et en 1997 il passa le relais à Olaf Weber.
Le système Web2C fonctionne sur Unix, les systèmes Windows 32 bits, Mac OS X et de nombreux autres systèmes d’exploitation. Il utilise les sources originales de D.E. Knuth pour TeX et les autres programmes de base écrits en web qui sont tous traduits en langage C. Les composants du noyau de TeX sont :
La syntaxe et les fonctions précises de ces programmes sont décrites dans la documentation des composants individuels et dans le manuel Web2C lui-même. Toutefois, connaître un certain nombre de principes régissant l’ensemble de la famille de programmes peut aider à exploiter de façon optimale votre installation Web2c.
Presque tous ces programmes suivent les options standard de GNU :
Pour localiser les fichiers, les programmes Web2c utilisent la bibliothèque de recherche Kpathsea. Cette bibliothèque utilise une combinaison de variables d’environnement et un certain nombre de fichiers de paramètres pour optimiser la recherche dans l’énorme arborescence TeX. Web2C peut exécuter une recherche dans plusieurs arborescences simultanément, ce qui est utile si l’on souhaite maintenir la distribution standard de TeX et les extensions locales dans deux arborescences distinctes. Afin d’accélérer la recherche de fichiers, la racine de chaque arborescence possède un fichier ls-R contenant une entrée donnant le nom et le chemin de chaque fichier situé sous la racine.
Décrivons en premier lieu le mécanisme de recherche de la bibliothèque Kpathsea.
Nous appelons chemin de recherche une liste, séparée par « deux-points » ou « point-virgule », d’éléments, appelés éléments de chemin, qui sont des noms de répertoires. Un chemin de recherche peut provenir de plusieurs sources. Pour rechercher un fichier « my-file » le long d’un chemin « .:/dir », Kpathsea vérifie chaque élément du chemin : d’abord ./my-file, puis /dir/my-file, et renvoie la première occurrence (voire toutes).
Afin d’optimiser l’adaptation à tous les systèmes d’exploitation, Kpathsea peut utiliser dans les noms de fichiers des séparateurs différents de deux-points (« : ») et barre oblique (« / ») pour les systèmes non-Unix.
Pour vérifier un élément de chemin particulier p, Kpathsea vérifie d’abord si une base de données existante (voir page 78) contient p, c.-à-d. si la base de données se trouve dans un répertoire qui est un préfixe de p. Si oui, la spécification du chemin est comparée avec le contenu de la base de données.
Si la base de données n’existe pas, si elle ne s’applique pas à cet élément de chemin ou si elle ne contient aucune correspondance, la recherche est lancée sur tout le système de fichiers (si cela n’a pas été interdit par une commande commençant par « !! » et si le fichier cherché est censé exister). Kpathsea construit la liste de répertoires qui correspondent à cet élément de chemin, puis cherche le fichier dans chaque élément de cette liste.
La condition « le fichier est censé exister » est liée aux fichiers « .vf » et aux fichiers d’entrée lus par la commande TeX \openin. De tels fichiers peuvent ne pas exister (par exemple cmr10.vf), il est donc inutile de les rechercher sur le disque. De plus, si vous n’actualisez pas le fichier ls-R lors de l’installation d’un nouveau fichier « .vf », il ne sera jamais trouvé. Chaque élément de chemin est alors vérifié : d’abord dans la base de données puis sur le disque. Si une occurrence est trouvée, la recherche s’arrête et le résultat est obtenu.
Bien que l’élément de chemin le plus simple et le plus fréquent soit un nom de répertoire, Kpathsea supporte d’autres types d’éléments dans les chemins de recherche : des valeurs par défaut differentes pour chaque programme, des noms de variables d’environnement, des valeurs de fichiers de configuration, les répertoires de l’utilisateur et la recherche récursive de sous-répertoires. Nous disons alors que Kpathsea étend un élément, c’est-à-dire que Kpathsea transforme toutes ces spécifications en noms de répertoires de base. Cette opération est décrite dans les sections suivantes.
Notons que si le nom de fichier cherché est absolu ou explicitement relatif, c’est-à-dire commençant par « / », « ./ » ou « ../ », Kpathsea ne vérifie que l’existence de ce fichier.
Un chemin de recherche peut provenir de plusieurs sources. Voici l’ordre dans lesquel Kpathsea les utilise.
On peut voir chacune de ces valeurs pour un chemin de recherche donné en utilisant l’option de débogage (voir page 86).
Kpathsea lit dans les fichiers de configuration à l’exécution appelés texmf.cnf les chemins de recherche et d’autres définitions. Le chemin pour accéder à ces fichiers dans l’arborescence est stocké dans la variable TEXMFCNF (par défaut ces fichiers se trouvent dans le sous-répertoire texmf/web2c). Tous les fichiers texmf.cnf se trouvant dans le chemin de recherche vont être lus et les définitions provenant de fichiers précédents écraseront celles des fichiers suivants. Par exemple, avec un chemin tel que .:$TEXMF, les définitions du fichier ./texmf.cnf écrasent celles de $TEXMF/texmf.cnf.
Voici un fichier de configuration illustrant les points précédents
Kpathsea reconnaît certains caractères et constructions spéciales dans les chemins de recherche, semblables à ceux disponibles dans les shells Unix. Ainsi, le chemin complexe, ~$USER/{foo,bar}//bazétend la recherche vers tous les sous-répertoires situés sous les répertoires foo et bar dans le répertoire utilisateur $USER contenant un répertoire ou un fichier appelé baz. Ces expansions sont explicitées dans les sections suivantes.
Si le chemin de recherche le plus prioritaire (voir section 8.1.1) contient un « : » supplémentaire (c.-à-d. en début ou fin de ligne ou double), Kpathsea insère à cet endroit le chemin suivant dont la priorité définie est immédiatement inférieure. Si ce chemin inséré possède un « : » supplémentaire, le même processus se répète pour le chemin prioritaire suivant. Par exemple, étant donné une variable d’environnement définie ainsi
Comme il est inutile d’insérer la valeur par défaut en plusieurs endroits, Kpathsea applique la substitution à seulement un « : » supplémentaire et laisse les autres inchangés : il cherche d’abord un « : » en début de ligne, puis en fin de ligne et enfin un double « : ».
Option utile, l’expansion par le biais des accolades signifie, par exemple, que v{a,b}w va permettre la recherche dans vaw:vbw. Les définitions emboîtées sont autorisées. Ceci peut être utilisé pour établir des hiérarchies TeX multiples en attribuant une liste entre accolades à $TEXMF. Par exemple, dans texmf.cnf, on trouve (ligne 52) la définition suivante :
Avec ceci, on peut écrire quelque chose comme
ce qui signifie que, après avoir cherché dans le répertoire courant, les arborescences complètes $HOMETEXMF suivie de $TEXMFLOCAL/tex (sur le disque) et ensuite les arborescences !!$VARTEXMF et !!$TEXMFMAIN/tex (définies dans le fichier de référence ls-Rseulement) seront inspectées. C’est un moyen pratique permettant d’utiliser en parallèle deux distributions TeX, une « gelée » (sur un CD, par exemple) et une autre régulièrement mise à jour avec de nouvelles versions quand elles deviennent disponibles. En utilisant la variable $TEXMF dans toutes les définitions, on est toujours sûr d’inspecter d’abord l’arborescence la plus récente.
Deux barres « // » ou plus consécutives dans une partie d’un chemin suivant un répertoire d sont remplacées par tous les sous-répertoires de d : d’abord les sous-répertoires directement présents dans d, ensuite les sous-répertoires de ceux-ci, et ainsi de suite. À chaque niveau, l’ordre dans lequel les répertoires sont inspectés est non-déterminé.
Dans le cas où l’on spécifie une partie de nom de fichier après le « // », seuls sont inclus les sous-répertoires auxquels le nom correspond. Par exemple, « /a//b » va correspondre aux répertoires /a/1/b, /a/2/b, /a/1/1/b, et ainsi de suite, mais pas à /a/b/c ni /a/1.
Des « // » multiples et successifs dans un chemin sont possibles, mais « // » au début d’un chemin est ignoré.
La liste suivante récapitule la signification des caractères spéciaux dans les fichiers de configuration de Kpathsea.
Kpathsea a une certaine profondeur d’investigation pour minimiser les accès disque durant les recherches. Néanmoins, dans le cas de distributions comprenant beaucoup de répertoires, inspecter chaque répertoire possible pour un fichier donné peut durer excessivement longtemps (ceci est typiquement le cas quand plusieurs centaines de répertoires de polices de caractères doivent être parcourus). En conséquence, Kpathsea peut utiliser un fichier texte appelé ls-R — en fait une base de données construite au préalable — qui fait correspondre les fichiers à leur répertoire, ce qui permet d’éviter une recherche exhaustive sur le disque.
Un deuxième fichier appelé aliases (qui est également une base de données) permet de donner des noms différents aux fichiers listés dans ls-R. Ceci peut aider à adapter ses fichiers source aux conventions de DOS 8.3 pour les noms de fichiers.
Comme nous l’avons expliqué ci-dessus, le nom du principal fichier-base de données doit être ls-R. Dans votre installation, vous pouvez en mettre un à la racine de chaque arborescence TeX que vous désirez voir inspecter ($TEXMF par défaut) ; la plupart des sites ont une seule arborescence TeX. Kpathsea cherche les fichiers ls-R dans le chemin spécifié dans la variable TEXMFDBS.
La meilleure façon de créer et mettre à jour le fichier « ls-R » est d’exécuter le script mktexlsr inclus dans la distribution. Il est appelé par les divers scripts mktex. . . En principe, ce script exécute uniquement la commande
Si un fichier n’est pas trouvé dans la base de données, par défaut Kpathsea décide de le chercher sur le disque. Par contre, si un élément du chemin commence par « !! », seule la base de données sera inspectée pour cet élément, jamais le disque.
Le programme kpsewhich effectue une recherche dans une arborescence indépendamment de toute application. On peut le considérer comme une sorte de find pour localiser des fichiers dans les arborescences TeX (ceci est largement utilisé dans les scripts mktex. . . de la distribution).
Kpathsea considère tout argument non optionnel dans la ligne de commande comme un nom de fichier et renvoie la première occurrence trouvée. Il n’y a pas d’option pour renvoyer tous les fichiers ayant un nom particulier (vous pouvez utiliser le find d’Unix pour cela).
Les options les plus importantes sont décrites ci-après.
Les deux dernières entrées du tableau 3 sont des cas spéciaux, car les chemins et les variables d’environnement dépendent du nom du programme : le nom de la variable est construit en convertissant le nom du programme en majuscule et en y ajoutant INPUTS.
Les variables d’environnement sont définies par défaut dans le fichier de configuration texmf.cnf. C’est seulement quand on veut redéfinir une ou plusieurs variables dans ce fichier que l’on a intérêt à les définir alors explicitement dans son propre environnement d’exécution.
Les options de « --format » et « --path » s’excluent mutuellement.
Jetons un coup d’œil à Kpathsea en action ; voici une recherche toute simple :
Le dernier exemple est une base de données bibliographiques pour BIBTeX servant aux articles de TUGBoat.
Intéressons-nous à présent aux fichiers d’entête et de configuration pour dvips. Regardons en premier le fichier tex.pro communément utilisé pour le support de TeX avant de regarder le fichier de configuration générique (config.ps) et la liste des fontes PostScript psfonts.map. Comme le suffixe « .ps » est ambigu, nous devons spécifier quel type particulier du fichier config.ps nous considérons (dvips config).
Regardons plus en détail les fichiers de support Times PostScript d’URW. Leur nom standard dans le schéma de nommage des fontes est « utm ». Le premier fichier que nous voyons est le fichier de configuration, qui contient le nom du fichier de la liste :
Il devrait être clair, d’après ces quelques exemples, qu’il est facile de trouver l’endroit où se cache un fichier donné. C’est particulièrement important si vous suspectez que c’est, pour une raison quelconque, une mauvaise version du fichier qui est utilisée, puisque kpsewhich va vous montrer le premier fichier trouvé.
Il est quelquefois nécessaire de savoir comment un programme référence les fichiers. Pour permettre cela, Kpathsea offre plusieurs niveaux de débogage :
Une valeur de -1 activera toutes les options ci-dessus ; en pratique, c’est habituellement la valeur la plus adaptée.
De la même façon, avec le programme dvips, en utilisant une combinaison d’options de débogage, on peut suivre en détail la localisation des différents fichiers. De plus, lorsqu’un fichier n’est pas trouvé, la trace du débogage montre les différents répertoires dans lesquels le programme va chercher tel ou tel fichier, donnant ainsi des indices sur le problème.
Généralement, comme la plupart des programmes appellent la bibliothèque Kpathsea en interne, on peut sélectionner une option de débogage en utilisant la variable d’environnement KPATHSEA_DEBUG, et en la définissant égale à la valeur (ou à une combinaison de valeurs) décrite(s) dans la liste ci-dessus.
Note à l’intention des utilisateurs de Windows : il n’est pas facile de rediriger les messages d’erreur vers un fichier sur ces systèmes. À des fins de diagnostic, vous pouvez temporairement affecter KPATHSEA_DEBUG_OUTPUT=err.log pour capturer le flux standard d’erreur dans le fichier err.log.
Considérons comme exemple un petit fichier source LaTeX, hello-world.tex, dont le contenu est le suivant.
Ce petit fichier utilise simplement la fonte cmr10, aussi allons voir comment dvips prépare le fichier PostScript (nous voulons utiliser la version Type 1 des fontes Computer Modern, d’où l’option -Pcms).
debug:start search(file=texmf.cnf, must_exist=1, find_all=1,
path=.:/usr/local/bin/texlive:/usr/local/bin: /usr/local/bin/texmf/web2c:/usr/local: /usr/local/texmf/web2c:/.:/./teTeX/TeX/texmf/web2c:). kdebug:start search(file=ls-R, must_exist=1, find_all=1, path=~/tex:/usr/local/texmf). kdebug:search(ls-R) =>/usr/local/texmf/ls-R kdebug:start search(file=aliases, must_exist=1, find_all=1, path=~/tex:/usr/local/texmf). kdebug:search(aliases) => /usr/local/texmf/aliases kdebug:start search(file=config.ps, must_exist=0, find_all=0, path=.:~/tex:!!/usr/local/texmf/dvips//). kdebug:search(config.ps) => /usr/local/texmf/dvips/config/config.ps kdebug:start search(file=/root/.dvipsrc, must_exist=0, find_all=0, path=.:~/tex:!!/usr/local/texmf/dvips//). search(file=/home/goossens/.dvipsrc, must_exist=1, find_all=0, path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//). kdebug:search($HOME/.dvipsrc) => kdebug:start search(file=config.cms, must_exist=0, find_all=0, path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//). kdebug:search(config.cms) =>/usr/local/texmf/dvips/cms/config.cms
kdebug:start search(file=texc.pro, must\_exist=0, find\_all=0,
path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//: ~/tex/fonts/type1//:!!/usr/local/texmf/fonts/type1//). kdebug:search(texc.pro) => /usr/local/texmf/dvips/base/texc.pro
kdebug:start search(file=cmr10.tfm, must\_exist=1, find\_all=0,
path=.:~/tex/fonts/tfm//:!!/usr/local/texmf/fonts/tfm//: /var/tex/fonts/tfm//). kdebug:search(cmr10.tfm) => /usr/local/texmf/fonts/tfm/public/cm/cmr10.tfm kdebug:start search(file=texps.pro, must\_exist=0, find\_all=0, ... <texps.pro> kdebug:start search(file=cmr10.pfb, must\_exist=0, find\_all=0, path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//: ~/tex/fonts/type1//:!!/usr/local/texmf/fonts/type1//). kdebug:search(cmr10.pfb) => /usr/local/texmf/fonts/type1/public/cm/cmr10.pfb <cmr10.pfb>[1]
|
dvips commence par localiser ses fichiers de fonctionnement. D’abord, texmf.cnf est trouvé, ce qui donne les définitions pour les chemins de recherche servant à localiser les autres fichiers, ensuite le fichier base de données ls-R (pour optimiser la recherche des fichiers) et le fichier aliases, qui permet de déclarer plusieurs noms (p.ex., un nom DOS de type 8.3 court et une version longue plus naturelle) pour le même fichier. Ensuite dvips continue en cherchant le fichier de configuration générique config.ps avant de rechercher le fichier de paramétrisation .dvipsrc (qui, dans notre cas, n’est pas trouvé). Enfin, dvips localise le fichier de configuration pour les fontes PostScript Computer Modern config.cms (ceci est lancé par l’option -Pcms de la commande dvips). Ce fichier contient la liste des fichiers qui définissent la relation entre les noms des fontes selon TeX, selon PostScript et dans le système de fichiers.
Arrivé là, dvips s’identifie à l’utilisateur :
pour continuer ensuite en cherchant le fichier prolog texc.pro,
Après avoir trouvé ce fichier, dvips affiche la date et l’heure, et nous informe qu’il va générer le fichier hello-world.ps, puis qu’il a besoin du fichier de fonte cmr10, et que ce dernier est déclaré comme « resident » (pas besoin de bitmaps) :
Web2C offre la possibilité de contrôler à l’exécution bon nombre de paramètres concernant la mémoire (en particulier la taille des tableaux utilisés) à partir du fichier texmf.cnf qui est lu par Kpathsea. Les paramètres en question se trouvent dans la troisième partie du fichier inclus dans la distribution TeX Live. Les variables les plus importantes sont :
Évidemment, cette possibilité ne remplace pas une véritable allocation dynamique des tableaux et de la mémoire, mais puisque c’est complexe à implémenter dans le présent source TeX, ces paramètres lus à l’exécution fournissent un compromis pratique qui procure une certaine souplesse.