6 Le 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. L’implémentation a été dirigée par Tomas Rokicki qui, en 1987, a dévelopé un premier système TeX-to-C en adaptant les fichiers sous Unix, qui était 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 douzaines de collaborateurs, et en 1997 il passa le relais à Olaf Weber. Le dernière version en date est Web2c Version 7.3, qui parut en mars 1999, et qui forme les bases du présent TeX Live CD-ROM.

Le système Web2c 7.3 fonctionne sur Unix, Windows 3.1, 9x/NT, DOS, Amiga et de nombreux autres systèmes d’exploitation. Il utilise les sources originales de Knuth pour TeX et les autres programmes de base écrits en web pour les traduire en langage C. De plus, le système offre un large éventail de macros et de fonctions dévelopé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

Expansion de fontes virtuelles.

dvitomp

DVI vers MPX (dessins MetaPost).

dvitype

DVI vers texte.

gftodvi

Fontes génériques vers épreuves.

gftopk

Fontes génériques vers fontes bitmap.

gftype

GF vers texte.

makempx

Typographie des étiquettes MetaPost.

mf

Creation 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

Creating hyphenation patterns.

pktogf

Fontes bitmap vers fontes generiques.

pktype

PK vers texte.

pltotf

PL vers TFM.

pooltype

Affiche les fichiers web pool.

tangle

web vers Pascal.

tex

Typographie.

tftopl

TFM vers PL.

vftovp

Fontes virtuelles vers PL virtuelles.

vptovf

PL virtuelles vers fontes virtuelles.

weave

web vers TeX.

La syntaxe et les fonctions précises de ces programmes sont décrites dans la documentation des composants individuels ou bien dans le manuel Web2c lui même. Toutefois, la connaissance d’un certain nombre de principes gouvernant l’ensemble de la famille de programmes peut vous aider à exploiter de façon optimale votre installation Web2c. 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 le numéro de version, puis quitte.

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 configuration pour optimiser la recherche dans l’arborescence TeX. Web2c 7.3 peut chercher plusieurs arborescences de fichiers 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.

6.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 avec « deux-points » ou « point-virgule », dont les éléments, appelés éléments de chemin, 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 retourne la (ou les) bonne(s) correspondance(s).

Afin d’optimiser l’adaptation à tous les systèmes d’exploitaion, 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 32) s’applique à p, i.e. 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és n’existe pas, ne s’applique pas à cet élément de chemin ou 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é doit 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 doit exister” entre en jeu avec les fichiers “.vf” et les fichiers d’entrée lus par la commande TeX’s \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 correspondance est trouvée la recherche s’arrête et le résultat est retourné.

Bien que l’élément de chemin le plus simple et banal soit un nom de répertoire, Kpathsea supporte d’autres formats 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 basiques. Ce qui est décrit dans les sections suivantes.

Notez que si le nom de fichier cherché est absolu ou explicitement relatif, c’est-à-dire commençant par “/”, “./” ou “../”, Kpathsea vérifie seulement si ce fichier existe.

6.1.1 Les différentes sources

Un chemin de recherche peut provenir de plusieurs sources. Dans l’ordre dans lesquels Kpathseah les utilise :

1. une variable d’evironnement 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 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 à la compilation

Vous pouvez voir chacune de ces valeurs pour un chemin de recherche donné en utilisant l’option de débogage voir page 41).

6.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 dans l’ordre et les définitions provenant des premiers fichiers lus écraseront celles des fichiers suivants. Par exemple, avec un chemin tel que .:$TEXMF, les définitions du fichier ./texmf.cnf écrasent celles présentes dans $TEXMF/texmf.cnf.

En complément de la lecture du descriptif du format du fichier texmf.cnf ci-dessous, on doit aussi se référer à l’annexe 9, commençant page 50, qui liste le fichier texmf.cnf donné avec la distribution sur le CDRom.

• Les commentaires sont signalés par un “%” et continuent jusqu‘à 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 optionels.
• Le nom de la “variable” peut contenir n’importe quels caractères exceptés les espaces, “=”, ou “.”, mais on recommande de se cantonner à “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 à différentes distributions de TeX d’avoir des chemins de recherche différents par exemple.
• “value” peut contenir n’importe quels caractères exceptés “%” 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 car permettant 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 puissent être référencées avant d’être définies.

Un extrait d’un fichier de configuration illustrant les points précédents est présenté ci-dessous:

6.1.3 Expansion d’un chemin de recherche

Kpathsea reconnaît certain caractères et constructions spéciaux dans les chemins de recherche, semblables à ceux disponibles dans les shells Unix. Comme exemple général, 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 de $USER contenant un répertoire ou un fichier appelé baz. Ces expansions sont explicitées dans les sections suivantes.

6.1.4 Expansion par défault

Si le chemin de recherche le plus prioritaire (voir “Origines des chemins” en page 28) contient un “:” supplémentaire (c’est à dire, en début ou fin de ligne ou double), Kpathsea insère à cet endroit le prochain chemin de priorité immédiatement inférieure défini. Si ce chemin inséré possède un “:” supplémentaire, le même processus se répète pour le prochain chemin prioritaire. Par exemple, étant donnée une variable d’environnement définie comme suit

Comme il serait inutile d’insérer la valeur par défaut à 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 et enfin pour un double “:”.

6.1.5 Expansion spécifiée par les accolades

Une option utile est l’expansion par le biais des accolades, ce qui signifie par exemple que, v{a,b}w va permettre la recherche dans vaw:vbw. Les définitions emboité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, l’arborescence complète $TEXMFLOCAL/tex (sur le disque) et ensuite l’arborescence !!$TEXMFMAIN/tex (définie dans le fichier de référence ls-R seulement) seront inspectés. C’est un moyen pratique permettant d’utiliser en parallèle deux distributions TeX, une première “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.

6.1.6 Expansion des sous-répertoires

Deux ou plus slashes consécutifs dans une partie d’un chemin suivant un répertoire d est remplacé 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. A chaque niveau, l’ordre dans lequel les répertoires sont inspectés est indé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 dont 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é.

6.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, c’est à dire 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 (permets les entrées sur de multiples lignes).

!!

Recherche seulement dans la base de données pour localiser le fichier et pas sur le disque.

6.2 Les bases de données des fichiers

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 si plusieurs centaines de répertoires de polices de caractères doivent être parcourus.) En conséquence, Kpathsea peut utiliser un fichier-base de données construite au préalable et appelée named ls-R qui fait correspondre les fichiers à leur répertoire, ce qui permet d’èviter une recherche exhaustive sur le disque.

Un deuxième fichier-base de données aliases 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.

6.2.1 La base de données des fichiers

Comme expliqué ci-dessus, le nom du principal fichier-base de données doit être ls-R. Vous pouvez en mettre un dans la racine de chaque architecture TeX dans votre installation que vous désirez être inspectée ($TEXMF par défaut); la plupart des sites ont seulement une architecture. Kpathsea cherche les fichiers ls-R dans le chemin spécifié dans la variable TEXMFDBS.

La façon recommendée de créer et mettre à jour le fichier “ls-R” est d’exécuter le script mktexlsr inclus dans la distribution. Il est invoqué par les divers scripts “mktex”. . . n 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 chercher sur le disque. Par contre, si un élément du chemin commence par “!!”, seulement la base de données sera inspectée pour cet élément, et jamais le disque.

6.2.2 kpsewhich: programme de recherche dans une arborescence

Le programme kpsewhich effectue une recherche dans une arborescence indépendamment de toute application. Il peut être considéré comme une sorte de find pour localiser des fichiers dans les arborescences TeX (ceci est largement utilisé dans les scripts “mktex”. . .  venant avec la distribution).

Kpathsea considère tout argument non optionnel dans la ligne de commande comme un nom de fichier et renvoie la première occurence 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.

Le 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 de recherche à “name”. Par défaut, le format est supposé d’après le nom de fichier. Pour les formats qui n’ont pas de suffixe non-ambigu aui leur est 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, qui liste les noms reconnus à ce jour, une description, les variables d’environnement associées¹, et les extensions de nom de fichier autorisées.

Table 1: Kpathsea file types Noms Description Variables Suffixes afm Adobe font metrics AFMFONTS .afm base Metafont memory dump MFBASES, TEXMFINI .base bib BIBTeX bibliography source BIBINPUTS, TEXBIB .bib 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 FONTS, GFFONTS, GLYPHFONTS, TEXFONTS .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 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 fontes bitmap compressées 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 fichiers texte utilisés par ‘foo’ FOOINPUTS other binary files fichiers binaire utilisés par ‘foo’ FOOINPUTS

Les deux dernières entrées de la Table 1 sont des cas spéciaux, où 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 majuscules, et en y ajoutan 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 environnement d’exécution.

Notez que les options de “format” et “path” sont mutuellement exclusives.

mode=string

Definit le nom du mode comme étant “string”; ceci affecte seulement la recherche des “gf” et des “pk”. Pas de défaut: n’importe quel mode sera trouvé.

must-exist

Fait tout ce qui est possible pour trouver les fichiers, ce qui inclut rechercher sur le disque. Par défaut, seulement 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 des deux-points comme d’habitude), au lieu de supposer le chemin à partir du nom de fichier. “//” et toutes les expansions habituelles sont supportées. Les options “path” et “format” sont mutuellement exclusives.

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”. C’est 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éboggages comme étant “num”.

6.2.3 Exemples d’utilisation

Jetons un coup d’oeil à Kpathsea en action.

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

Regardons à présent l’entête dvips et les fichiers de configuration. 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 carte 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 URW Times PostScript. Leur nom dans le schéma d’appelation de fontes de Berry est “utm”. Le premier fichier que nous voyons est le fichier de configuration, qui contient le nom du fichier d’organisation:

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

6.2.4 Opérations de déboggage

Quelquefois il est nécessaire de savoir comment un programme référence les fichiers. Pour permettre cela d’une manière pratique, Kpathsea offre plusieurs niveaux de déboggage:

• 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 tables de découpage (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 générale sur la localisation des types de fichier recherchés par Kpathsea. Ceci est utile pour trouver où a été défini le chemin particulier pour un fichier.
• La 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; dans la pratique, vous utiliserez probablement ces niveaux si vous avez besoin de débogger.

De la même façon, avec le programme dvips, en utilisant une combinaison d’option de déboggage, on peut savoir en détail où les différents fichiers sont pris. En parallèle, lorsqu’un fichier n’est pas trouvé, le log du déboggage 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 appelent la bibliothèque Kpathsea en interne, on peut sélectionner une option de déboggage en utilisant la variable d’environnement KPATHSEA_DEBUG, et en la fixant égale à (une combinaison) des valeurs décrites dans la liste ci-dessus.

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 Type1 des fontes Computer Modern, d’où l’option -Pcms).

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

6.3 Options à l’exécution

Web2c 7.3 offre la possibilité de contrôler à l’exécution bon nombre des paramètres concernant la mémoire et en particulier la taille des tableaux utilisés; il suffit de spécifier les valeurs dans le fichier texmf.cnf qui est lu par Kpathsea. Le listing de ce fichier est fourni en annexe 9, à partir de la page 50; 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 and 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 (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 (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, glu, 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.