7 Guide d’utilisation du système Web2c
Web2c contient un ensemble de programmes relatifs à TeX, c.-à-d. TeX lui-même, METAFONT, MetaPost,
BIBTeX, etc. 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 fichiers sous Unix qui étaient principalement le travail de Howard Trickey et
Pavel Curtis. 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. La dernière version en date est Web2c Version 7.3, parue en mars 1999, qui forme la base du
présent TeX Live CD-ROM. Notre version diffère légèrement et s’identifie comme étant la version
7.3.7.
Le système Web2c 7.3 fonctionne sur Unix, Windows 3.1, 9x/ME/NT/2K/XP, DOS, et de nombreux autres
systèmes d’exploitation. Il utilise les sources originales de D.E. Knuth pour TeX et d’autres programmes de base
écrits en web qui sont tous traduits en langage C. De plus, le système offre un large éventail de macros et de
fonctions développées dans le but d’améliorer le logiciel TeX original. Les composantes du noyau de TeX sont
:
-
bibtex
- Gère les bibliographies.
-
dmp
- troœ 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 gouvernant 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’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 pour chaque
fichier situé sous la racine.
7.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 occurence (plus largement :
toutes les occurences).
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 « slash » (« / ») 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 70) 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 » entre en jeu avec les fichiers « .vf » et les 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 occurence 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. Ce qui est décrit
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.
7.1.1 Les différentes sources
Un chemin de recherche peut provenir de plusieurs sources. Voici l’ordre dans lesquel Kpathsea les
utilise.
- 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.
- Un fichier de configuration de programme spécifique, par exemple une ligne « S /a:/b » dans le
config.ps de dvips.
- Un fichier de configuration texmf.cnf de Kpathsea contenant une ligne telle que
« TEXINPUTS=/c:/d »
(voir ci-dessous).
- La valeur par défaut obtenue à la compilation.
Vous pouvez voir chacune de ces valeurs pour un chemin de recherche donné en utilisant l’option de débogage
(voir page 79).
7.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 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.
En sus de la lecture du descriptif du format du fichier texmf.cnf ci-dessous, on doit aussi se référer à
l’annexe 11, à la page 90, qui liste le fichier texmf.cnf de la distribution sur le CD-ROM.
- Les commentaires sont signalés par un « % » et se terminent à la fin de la ligne.
- Les lignes vierges sont ignorées.
- Un \ à la fin d’une ligne joue le rôle d’un lien entre deux lignes, c’est à dire que la ligne courante
se poursuit à la ligne suivante. Dans ce cas, les espaces présents au début de la ligne suivante ne
sont pas ignorés.
- Toutes les autres lignes sont de la forme :
variable[.progname] [=] value
où le « = » et les espaces autour sont optionnels.
- Le nom de la « variable » peut contenir n’importe quel caractère autre que les espaces, « = », ou « . »,
mais on recommande d’utiliser « A-Za-z_ » pour éviter les problèmes.
- Si « .progname » est présent, sa définition s’applique seulement si le programme exécuté se nomme
progname ou progname.exe. Ceci permet par exemple à différentes variantes de TeX d’avoir des
chemins de recherche différents.
- « value » peut contenir n’importe quel caractère excepté « % » et « @ ». L’option « $var.prog » n’est
pas disponible à droite ; à la place, on doit utiliser une variable supplémentaire. Un « ; » dans « value »
est compris comme un « : » si on travaille sous Unix ; ceci est très utile et permet d’avoir un seul
texmf.cnf pour les systèmes Unix, MSDOS et Windows.
- Toutes les définitions sont lues avant tout désarchivage ou décompactage, de telle façon que les variables
peuvent être référencées avant d’être définies.
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;}//
7.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.
7.1.4 Expansion par défaut
Si le chemin de recherche le plus prioritaire (voir section 7.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
alors la valeur finale utilisée pour la recherche sera :
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 « : ».
7.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-R seulement) seront inspectées. C’est un moyen pratique permettant
d’utiliser en parallèle deux distributions TeX, une « gelée » (sur un CD-ROM, 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.
7.1.6 Expansion des sous-répertoires
Deux slashes ou plus consécutifs dans une partie d’un chemin suivant un répertoire d sont remplacés 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 ou /a/1.
Des « // » multiples et successifs dans un chemin sont possibles, mais « // » au début d’un chemin est
ignoré.
7.1.7 Liste des caractères spéciaux et leur signification : un 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.
7.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 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 « 8.3 » pour
les noms de fichiers dans les systèmes similaires à DOS.
7.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 seulement une 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.
7.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 « - » ou « -- », et 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 les recherches des « 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 1. Cette table regroupe les
noms reconnus à ce jour, accompagnés d’une description et des variables d’environnement
associées9
et les extensions possibles.
TAB. 1: | Kpathsea file types |
|
Name | 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 |
compiled
process
files
|
OCPINPUTS |
.ocp |
ofm |
font
metrics
|
OFMFONTS,
TEXFONTS |
.ofm,
.tfm |
opl |
property
lists
|
OPLFONTS,
TEXFONTS |
.opl |
otp |
translation
process
files
|
OTPINPUTS |
.otp |
ovf |
virtual
fonts
|
OVFFONTS,
TEXFONTS |
.ovf |
ovp |
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 |
type1
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 de la table 1 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.
Notons que 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 que le nom de programme est « 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 ».
7.2.3 Exemples d’utilisation
Jetons un coup d’œil à Kpathsea en action.
>> 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.
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 Type1 sur le CD-ROM).
>> 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 600 dpi (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 300 dpi (-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 communément utilisé tex.pro 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 URW Times PostScript. Leur nom dans le schéma
d’appellation de fontes de Berry 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 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 Type1 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 Regular utmr8a.pfb et trouvons sa position dans l’arborescence texmf en
utilisant une recherche applicable aux fichiers de fontes de Type1 :
>> 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, la
mauvaise version du fichier qui est utilisée, puisque kpsewhich va vous montrer le premier fichier
trouvé.
7.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 de
manière pratique, Kpathsea offre plusieurs niveaux de débogage :
- stat calls (tests 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.
- Références aux différentes tables (comme la base de données ls-R, les fichiers d’organisation, les
fichiers de configuration).
- Opérations d’ouverture et de fermeture des fichiers.
- 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.
- Liste des répertoires pour chaque élément du chemin (utilisé uniquement en cas de recherche sur
le disque).
- Recherche de fichiers.
Une valeur de -1 activera toutes les options ci-dessus ; en pratique, vous utiliserez probablement ces niveaux si
vous avez besoin de déboguer.
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 à valeur ou une combinaison des valeurs décrites 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 Type1 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 10 (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 10: | 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 11: | 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 12: | 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 7.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 5.78 Copyright 1998 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 »
:
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 Type1 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]
7.3 Options à l’exécution
Web2c offre la possibilité de contrôler à l’exécution bon nombre des paramètres concernant la mémoire (en
particulier la taille des tableaux utilisés) à partir du fichier texmf.cnf qui est lu par Kpathsea. Le listing de ce
fichier est fourni en annexe 11, à partir de la page 90 ; les paramètres en question se trouvent dans la troisième
partie de ce fichier. 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 10000 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 pdÆatex demandent 15 000 séquences de contrôle
supplémentaires (la valeur par défaut est 0).
Évidemment, cette possibilité ne remplace pas une vraie allocation dynamique des tableaux et de la mémoire,
mais puisque c’est complexe à implémenter, ces paramètres lus à l’exécution fournissent un compromis pratique
qui procure une certaine souplesse.