8 Guide d’utilisation du système Web2C

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 :

bibtex
Gère les bibliographies.
dmp
troff vers MPX (dessins MetaPost).
dvicopy
Copie le fichier DVI en supprimant les fontes virtuelles.
dvitomp
Convertit le fichier DVI en MPX (dessins MetaPost).
dvitype
Convertit le fichier DVI en un texte lisible.
gftodvi
Visualisation de fontes génériques GF.
gftopk
Convertit les fontes génériques GF en fontes bitmap PK.
gftype
Convertit le fichier GF en un texte lisible.
makempx
Typographie des étiquettes MetaPost.
mf
Création de fontes.
mft
Mise en page de code source METAFONT.
mpost
Création de diagrammes techniques.
mpto
Extraction d’étiquettes MetaPost.
newer
Comparaison de dates de modification (fichiers).
patgen
Création de motifs de césure.
pktogf
Convertit les fontes bitmap PK en fontes génériques GF.
pktype
Convertit les fontes PK en un texte lisible.
pltotf
Convertit les fichiers PL (lisibles) en TFM.
pooltype
Affiche les fichiers web pool.
tangle
web vers Pascal.
tex
Composition de textes.
tftopl
Convertit les fichiers TFM en PL (lisibles).
vftovp
Convertit les fontes virtuelles VF en VPL (lisibles).
vptovf
Convertit les fontes VPL en fontes virtuelles VF.
weave
web vers TeX.

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 :

--help
imprime le sommaire de l’utilisation,
--verbose
imprime le rapport détaillé du processus,
--version
imprime seulement le numéro de version.

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.

8.1 Kpathsea et la recherche de fichiers

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.

8.1.1 Les différentes sources

Un chemin de recherche peut provenir de plusieurs sources. Voici l’ordre dans lesquel Kpathsea les utilise.

  1. Une variable d’environnement définie par l’utilisateur, par exemple TEXINPUTS. Les variables d’environnement avec une extension attachée (nom de programme) sont d’abord prises en compte : par exemple, si « latex » est le nom du programme exécuté, TEXINPUTS.latex passera avant TEXINPUTS.
  2. Un fichier de configuration de programme spécifique, par exemple une ligne « S /a:/b » dans le fichier config.ps de dvips.
  3. Un fichier de configuration texmf.cnf de Kpathsea contenant une ligne telle que
    « TEXINPUTS=/c:/d » (voir ci-dessous).
  4. La valeur par défaut obtenue à la compilation.

On peut voir chacune de ces valeurs pour un chemin de recherche donné en utilisant l’option de débogage (voir page 86).

8.1.2 Fichiers de configuration

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


  TEXMF              = {$TEXMFLOCAL;!!$TEXMFMAIN}
  TEXINPUTS.latex    = .;$TEXMF/tex/{latex;generic;}//
  TEXINPUTS.fontinst = .;$TEXMF/tex//;$TEXMF/fonts/afm//
  % e-TeX related files
  TEXINPUTS.elatex   = .;$TEXMF/{etex;tex}/{latex;generic;}//
  TEXINPUTS.etex     = .;$TEXMF/{etex;tex}/{eplain;plain;generic;}//

8.1.3 Expansion d’un chemin de recherche

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.

8.1.4 Expansion par défaut

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


> setenv TEXINPUTS /home/karl:
la valeur de TEXINPUTS d’après le fichier texmf.cnfétant

  .:$TEXMF//tex
alors la valeur finale utilisée pour la recherche sera

  /home/karl:.:$TEXMF//tex

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 « : ».

8.1.5 Expansion spécifiée par les accolades

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 :


    TEXMF = {$HOMETEXMF,$TEXMFLOCAL,!!$VARTEXMF,!!$TEXMFMAIN}

Avec ceci, on peut écrire quelque chose comme


    TEXINPUTS = .;$TEXMF/tex//

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.

8.1.6 Expansion des sous-répertoires

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é.

8.1.7 Liste des caractères spéciaux et de leur signification : récapitulatif

La liste suivante récapitule la signification des caractères spéciaux dans les fichiers de configuration de Kpathsea.

:
Séparateur dans un chemin de recherche ; au début ou à la fin d’un chemin, il remplace le chemin par défaut.
;
Séparateur dans les systèmes non-Unix (joue le rôle de :).
$
Substitue le contenu d’une variable.
~
Représente le répertoire racine de l’utilisateur.
{... }
Expansion par les accolades, par exemple a{1,2}b devient a1b:a2b.
//
La recherche concernera aussi les sous-répertoires (peut être inséré n’importe où dans un chemin sauf au début).
%
Début d’un commentaire.
\
Caractère de continuation de ligne (permet les entrées sur plusieurs lignes).
!!
Cherche seulement dans la base de données pour localiser le fichier et ne cherche pas sur le disque.

8.2 Les bases de données

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.

8.2.1 Le fichier base de données

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


cd /your/texmf/root && ls -LAR ./ >ls-R
en supposant que la commande ls de votre système produise le bon format de sortie (le ls de GNU convient parfaitement). Pour s’assurer que la base de données est toujours à jour, le meilleur moyen est de la reconstruire en utilisant la table des cron, de telle façon que le fichier ls-R prenne automatiquement en compte les changements dans les fichiers installés —  peut-être après avoir installé ou mis à jour un composant LaTeX.

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.

8.2.2 kpsewhich : programme de recherche dans une arborescence

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).


> kpsewhich option... filename...
Les options spécifiées dans option peuvent commencer soit par « - » soit par « -- » ; n’importe quelle abréviation claire est acceptée.

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.

--dpi=num

Définit la résolution à num ; ceci affecte seulement la recherche des fichiers « gf » et « pk ». « -D » est un synonyme pour assurer la compatibilité avec dvips. Le défaut est 600.
--format=name

Définit le format pour la recherche à name . Par défaut, le format est estimé en fonction du nom de fichier. Pour les formats qui n’ont pas de suffixe clair associé, comme les fichiers de support MetaPost et les fichiers de configuration dvips, vous devez spécifier le nom correspondant à celui trouvé dans la première colonne de la table 3. Cette table regroupe les noms reconnus à ce jour, accompagnés d’une description et des variables d’environnement associées ainsi que de possibles extensions.
TAB. 3: Types de fichiers Kpathsea

Nom

Description
Variables
Suffixes

afm

Adobe font metrics

AFMFONTS

.afm

base

Metafont memory dump

MFBASES, TEXMFINI

.base

bib

BIBTeX bibliography source

BIBINPUTS, TEXBIB

.bib

bitmap fonts

GLYPHFONTS, TEXFONTS

bst

BIBTeX style files

BSTINPUTS

.bst

cnf

Runtime configuration files

TEXMFCNF

.cnf

dvips config

dvips configuration files, e.g., config.ps and psfonts.map

TEXCONFIG

.map

fmt

TeX memory dump

TEXFORMATS, TEXMFINI

.fmt, .efmt, .efm

gf

generic font bitmap

GFFONTS

.gf

graphic/figure

Encapsulated PostScript figures

TEXPICTS, TEXINPUTS

.eps, .epsi

ist

makeindex style files

TEXINDEXSTYLE, INDEXSTYLE

.ist

ls-R

Filename databases

TEXMFDBS

map

Fontmaps

TEXFONTMAPS

.map

mem

MetaPost memory dump

MPMEMS, TEXMFINI

.mem

mf

Metafont source

MFINPUTS

.mf

mfpool

Metafont program strings

MFPOOL, TEXMFINI

.pool

mft

MFT style file

MFTINPUTS

.mft

miscellaneous fonts

MISCFONTS

mp

MetaPost source

MPINPUTS

.mp

mppool

MetaPost program strings

MPPOOL, TEXMFINI

.pool

MetaPost support

MetaPost support files, used by DMP

MPSUPPORT

ocp

Omega compiled process files

OCPINPUTS

.ocp

ofm

Omega font metrics

OFMFONTS, TEXFONTS

.ofm, .tfm

opl

Omega property lists

OPLFONTS, TEXFONTS

.opl

otp

Omega translation process files

OTPINPUTS

.otp

ovf

Omega virtual fonts

OVFFONTS, TEXFONTS

.ovf

ovp

Omega virtual property lists

OVPFONTS, TEXFONTS

.ovp

pk

packed bitmap fonts

programFONTS (program being XDVI, etc.), PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS

.pk

PostScript header

downloadable PostScript

TEXPSHEADERS, PSHEADERS

.pro, .enc

tex

TeX source

TEXINPUTS

.tex, .cls, .sty, .clo, .def

TeX system documentation

Documentation files for the TeX system

TEXDOCS

TeX system sources

Source files for the TeX system

TEXSOURCES

texpool

TeX program strings

TEXPOOL, TEXMFINI

.pool

tfm

TeX font metrics

TFMFONTS, TEXFONTS

.tfm

Troff fonts

Troff fonts, used by DMP

TRFONTS

truetype fonts

TrueType outline fonts

TTFONTS

.ttf, .ttc

Type 1 fonts

Type 1 PostScript outline fonts

T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS

.pfa, .pfb

type42 fonts

Type 42 PostScript outline fonts

T42FONTS

vf

virtual fonts

VFFONTS, TEXFONTS

.vf

web2c files

Web2C support files

WEB2C

other text files

text files used by foo

FOOINPUTS

other binary files

binary files used by foo

FOOINPUTS

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.

--mode=string

Définit le nom du mode comme étant string ; ceci affecte seulement la recherche des « gf » et des « pk ». Pas d’option par défaut, n’importe quel mode sera trouvé.
--must-exist

Fait tout ce qui est possible pour trouver les fichiers, ce qui inclut une recherche sur le disque. Par défaut, seule la base de données ls-R est inspectée, dans un souci d’efficacité.
--path=string

Recherche dans le chemin string (séparé par deux-points comme d’habitude), au lieu de prendre le chemin à partir du nom de fichier. « // » et toutes les expansions habituelles sont supportées. Les options « --path » et « --format » s’excluent mutuellement.
--progname=name

Définit le nom de programme comme étant name . Ceci peut affecter les chemins de recherche via l’option .prognam dans les fichiers de configuration. Le défaut est kpsewhich.
--show-path=name

Montre le chemin utilisé pour la recherche des fichiers de type name . On peut utiliser soit une extension de fichier (.pk, .vf, etc.), soit un nom de fichier, comme avec l’option « --format ».
--debug=num

Définit les options de débogages comme étant num .

8.2.3 Exemples d’utilisation

Jetons un coup d’œil à Kpathsea en action ; voici une recherche toute simple :


> kpsewhich  article.cls
/usr/local/texmf/tex/latex/base/article.cls
Nous recherchons le fichier article.cls. Puisque le suffixe « .cls » est non-ambigu, nous n’avons pas besoin de spécifier que nous voulons rechercher un fichier de type tex (répertoires des fichiers sources de TeX). Nous le trouvons dans le sous-répertoire tex/latex/base du répertoire racine « TEXMF ». De même, le suffixe non-ambigu permet de trouver facilement les autres fichiers.

> kpsewhich array.sty
   /usr/local/texmf/tex/latex/tools/array.sty
> kpsewhich latin1.def
   /usr/local/texmf/tex/latex/base/latin1.def
> kpsewhich size10.clo
   /usr/local/texmf/tex/latex/base/size10.clo
> kpsewhich small2e.tex
   /usr/local/texmf/tex/latex/base/small2e.tex
> kpsewhich tugboat.bib
   /usr/local/texmf/bibtex/bib/beebe/tugboat.bib

Le dernier exemple est une base de données bibliographiques pour BIBTeX servant aux articles de TUGBoat.


> kpsewhich cmr10.pk
Les fichiers de glyphes de fontes bitmaps, de type .pk, sont utilisés pour l’affichage par des programmes comme dvips et xdvi. Rien n’est renvoyé dans ce cas puisque il n’y a pas de fichiers Computer Modern « .pk » pré-créés sur nos systèmes (puisque nous utilisons les versions Type 1 du TeX Live).

> kpsewhich ecrm1000.pk
   /usr/local/texmf/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk
Pour les fichiers de fontes Computer Modern étendues, nous avons dû créer les fichiers « .pk » et, puisque le mode METAFONT par défaut sur notre installation est ljfour avec une résolution de base de 600dpi (dots per inch), cette instance est trouvée.

> kpsewhich -dpi=300 ecrm1000.pk
Dans ce cas, lorsque l’on spécifie que nous sommes intéressés par une résolution de 300dpi (-dpi=300) nous voyons qu’aucune fonte pour cette résolution n’est disponible dans le système. En fait, un programme comme dvips ou xdvi ne s’en préoccuperait pas et créerait les fichiers .pkà la résolution demandée en utilisant le script mktexpk.

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).


> kpsewhich tex.pro
   /usr/local/texmf/dvips/base/tex.pro
> kpsewhich --format="dvips config" config.ps
   /usr/local/texmf/config/config.ps
> kpsewhich psfonts.map
   /usr/local/texmf/dvips/base/psfonts.map

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 :


> kpsewhich --format="dvips config" config.utm
/usr/local/texmf/dvips/psnfss/config.utm
Le contenu de ce fichier est

  p +utm.map
qui pointe vers le fichier utm.map, que nous cherchons à localiser ensuite.

> kpsewhich --format="dvips config" utm.map
  /usr/local/texmf/dvips/psnfss/utm.map
Ce fichier liste les noms des fichiers des fontes PostScript de Type 1 dans la collection URW. Son contenu ressemble à (nous ne montrons qu’une partie des lignes) :

utmb8r  NimbusRomNo9L-Medi    ... <utmb8a.pfb
utmbi8r NimbusRomNo9L-MediItal... <utmbi8a.pfb
utmr8r  NimbusRomNo9L-Regu    ... <utmr8a.pfb
utmri8r NimbusRomNo9L-ReguItal... <utmri8a.pfb
utmbo8r NimbusRomNo9L-Medi    ... <utmb8a.pfb
utmro8r NimbusRomNo9L-Regu    ... <utmr8a.pfb
Prenons par exemple le cas de Times Roman utmr8a.pfb et trouvons sa position dans l’arborescence texmf en utilisant une recherche applicable aux fichiers de fontes de Type 1 :

> kpsewhich utmr8a.pfb
  /usr/local/texmf/fonts/type1/urw/utm/utmr8a.pfb

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é.

8.2.4 Opérations de débogage

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 :

 1
Appels à stat (test d’existence de fichier). Lors d’une exécution utilisant une base de données ls-R à jour, ce niveau ne devrait donner presque aucune information en sortie.
 2
Références aux différentes tables (comme la base de données ls-R, les fichiers de correspondance de fontes, les fichiers de configuration).
 4
Opérations d’ouverture et de fermeture des fichiers.
 8
Information globale sur la localisation des types de fichiers recherchés par Kpathsea. Ceci est utile pour trouver où a été défini le chemin particulier pour un fichier.
16
Liste des répertoires pour chaque élément du chemin (utilisé uniquement en cas de recherche sur le disque).
32
Recherche de fichiers.

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.


    \documentclass{article}
    \begin{document}
    Hello World!
    \end{document}

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).


> dvips -d4100 hello-world -Pcms -o
Dans ce cas, nous avons combiné le niveau 4 de débogage de dvips (chemins des fontes) avec l’option d’expansion des éléments du chemin de Kpathsea (voir dvips Reference Manual, texmf/doc/html/dvips/dvips_toc.html). Nous obtenons quelque chose ressemblant à la figure 7 (nous avons réarrangé la sortie pour un affichage plus commode).
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
FIGURE 7: Finding configuration files
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
FIGURE 8: Finding the prolog file
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]
FIGURE 9: Finding the font file

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.


> more /usr/local/texmf/dvips/cms/config.cms
   p +ams.map
   p +cms.map
   p +cmbkm.map
   p +amsbkm.map
dvips veut chercher tous ces fichiers, y compris le fichier générique d’association psfonts.map, qui est toujours chargé (il contient des déclarations pour les fontes PostScript les plus communément utilisées ; voir la dernière partie de la Section 8.2.3 pour plus de détails sur la gestion du fichier d’association PostScript).

Arrivé là, dvips s’identifie à l’utilisateur :


 This is dvips(k) 5.92b Copyright 2002 Radical Eye Software (www.radicaleye.com)
 

pour continuer ensuite en cherchant le fichier prolog texc.pro,


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

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) :


TeX output 1998.02.26:1204’ -> hello-world.ps
Defining font () cmr10 at 10.0pt
Font cmr10 <CMR10> is resident.
Maintenant la recherche concerne le fichier cmr10.tfm, qui est trouvé, puis quelques fichiers prolog de plus (non montrés) sont référencés ; finalement le fichier de la fonte Type 1 cmr10.pfb est localisé et inclus dans le fichier de sortie (voir la dernière ligne).

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]

8.3 Options à l’exécution

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 :

main_memory
Nombre total de mots mémoire disponibles pour TeX, METAFONT et MetaPost. Vous devez générer un nouveau fichier de format pour chaque nouveau paramétrage. Par exemple, vous pouvez générer une version large de TeX et appeler le fichier de format hugetex.fmt. En utilisant la méthode supportée par Kpathsea qui consiste à suffixer la variable par le nom du programme, la valeur particulière de la variable main_memory destinée à ce fichier de format sera lue dans le fichier texmf.cnf sous le nom main_memory.hugetex (comparer la valeur générique à la valeur spécifique pour le format hugetex).
extra_mem_bot
Espace supplémentaire pour certaines structures de données de TeX : boîtes, glue, points d’arrêt. . . Surtout utile si vous utilisez PI CTeX par exemple.
font_mem_size
Nombre de mots mémoire disponibles pour décrire les polices. C’est plus ou moins l’espace occupé par les fichiers TFM lus.
hash_extra
Espace supplémentaire pour la table de hachage des noms de séquences de contrôle. Environ 10 000 de ces noms peuvent être stockés dans la table principale ; si vous avez un document très volumineux avec beaucoup de références croisées, il se peut que ce ne soit pas suffisant. Vous pouvez remarquer que aussi bien hugetex que pdflatex demandent 15 000 séquences de contrôle supplémentaires (la valeur par défaut est 0).

É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.