TDS : une structure de répertoires pour les fichiers TeX

Cahiers

enberg

GUT GUT GUT

m TDS : UNE STRUCTURE DE RÉPERTOIRES POUR LES FICHIERS TEX

Cahiers GUTenberg, n44-45 (2004), p. 83-114.

<http://cahiers.gutenberg.eu.org/fitem?id=CG_2004___44-45_83_0>

© Association GUTenberg, 2004, tous droits réservés.

L’accès aux articles desCahiers GUTenberg (http://cahiers.gutenberg.eu.org/),

implique l’accord avec les conditions générales

d’utilisation (http://cahiers.gutenberg.eu.org/legal.html).

Toute utilisation commerciale ou impression systématique est constitutive d’une infraction pénale. Toute copie ou impression de ce fichier doit contenir la présente mention de copyright.

TDS : une structure de répertoires pour les fichiers TEX

Groupe de travail TWG-TDS^∗

Traduction française de Jean-Côme Charpentier^† Postface de Fabrice Popineau

Avertissement.Cette note est latraductionfrançaise du documentA DirectoryStructurefor TEXFilespublié par leTUGWorkingGroup on aTEXDirectoryStructureetquiestdisponible,en diversformats,àhttp://tug.org/tds/.Elle n’a aucun caractère officiel.Cettetraduction estpubliéeiciavecl’aimable autorisation de KarlBerryau nom duTWG-TDS. La mise en page de cettetraduction suitcelleinitiale dela classetdsguide.cls,mais adaptée àla maquette desCahiersGUTenberg. [N.D.L.R.]

Copyright©1994, 1995, 1996, 1997, 1998, 1999,2003,2004 TEXUsers Group.Permis- sionto use,copy,and distributethis documentwithoutmodificationforanypurpose and without feeis herebygranted,providedthat this notice appearsin allcopies. It is provided“asis”withoutexpressed or implied warranty.Permissionis grantedto copy and distribute modifiedversions of this documentunder the conditionsfor verbatim copying,providedthat the modifications are clearlymarked andthe document is not represented asthe officialone. This document is available on anyCTAN host (see AppendixD).Please send questions orsuggestions byemail totds@ tug. org^.We welcome all comments. This is version 1.1.

Traduction françaisenon officielle

Ilestpermis d’utiliser,de copieretde distribuerce documentsans modification dans n’importe quelbutetsansfrais à condition que cette note(anglaise)apparaisse danstoutesles copies. Ilest fourni telquelsans garantie explicite ouimplicite. Il estpermis de copieretde distribuerdesversions modifiées de ce documentsous les conditions dela copieverbatim,étantentendu que ces modifications seront clairement indiquées etque ce documentne sera pas présenté commelaversion officielle.Ce documentestdisponible sur tousles sites CTAN(voirannexeD).Merci d’envoyerquestions ou suggestions àtds@tug.org^.Nous accueillerons avec plaisir tous les commentaires. Il s’agit ici de la version 1.1.

∗TWG-TDS=TUGWorkingGroup on aTEXDirectoryStructure.Sur la composition de ce groupe, voir la section E.

†La présente traduction est basée sur une celle de la version datant de 1999 (v 0.9996) qui avait été traduite conjointement avec Vincent Vaquin.

Avant-propos du traducteur

Lorsqu’on découvreTEX,un des aspects déroutants de ce système est le nombre impressionnantdefichiersinstallés surson disque dur. Il yen atantquel’on ne sait plus où donnerdelatête. Le problème devientcritiquelorsqu’on souhaiterapatrier unefonte,unfichierde style,une classe,etc.,depuis un site abbrctan(parexemple) sur son propre système.

Nombre de messagesfleurissentsur laliste de diffusion deGUTenberg oulesforums de discussion demandant «Bon, j’ai récupérétoto.mp^(outoto.sty^outoto.cls outoto.pdf) mais je le mets où ? »

Dansle« jeles mets où? »on a enfaitdeuxquestions. La première sous question est celle quetout le monde se posetrèsrapidement : « jele mets où pourqueTEXarrête de me dire qu’ilnetrouve paslefichier ? ».Force estde constaterque des pseudo- conseils sont trop souventprodiguésindiquantdele placeren un endroitoù se situe déjà un autrefichier.mp(respectivement.sty^,.cls^,.pdf^{).Certes,celava} fonctionner techniquementmais on se prépare alors deslendemains douloureux. La seconde sous question estmoins évidente au départmais elle devientcruellement évidentelors d’opérations particulières(migration surun autre poste,problème de fichiers homonymes,etc.).On pourrait laformulerdelafaçon suivante: « jele mets où pour que mon système ne soit pas un bazar infernal ? ».

Pourdonnerune petiteidée du problème,un systèmeTEXcourant (celuidel’auteur) va comporterdel’ordre d’un dizaine de milliers defichierstfm(métrique defonte), del’ordre de5 000 fichiersfv^{(fontevirtuelle)etentre500}et 1 000 fichierssty^{. Le} nombre de fichiers placés sous le répertoire racine principal de la distribution (par exemple/usr/share/texmf/^{sous Unix)dépasse}les 25 000.Onvoit vite quetout mettre dans un même répertoire n’est pas franchement une bonne idée !

Une première nécessité estdonc d’organiser,sipossibleintelligemment, l’arbores- cence du système pourqueles utilisateurs puissents’y retrouver facilement. Ici,

« utilisateur » est à prendre au sens large : ceux qui utilisent les fichiers sont à la fois les personnestapantun documentetdes programmes(TEX lui-même mais aussi les programmes de production defonte,de production d’index,devisualisation et d’impression,etc.).Une seconde nécessité a été d’inciter tout le monde à suivrela même organisation afin derendrelatâche de certains programmes plusfacile à gérer.

C’estpourcesraisons quele documentUne structure derépertoires pour lesfichiers TEXdevient indispensable.Suivrelesrecommandations des auteurs de ce docu- mentassure de disposerd’une organisation derépertoires quiafait l’objetd’une réflexionlongue etattentive de personnestrès compétentes et,d’autre part, va permettre àtousles programmes defonctionnerau mieuxmalgréles problèmes d’interdépendances.

Actuellement,toutesles distributions publiques ontadopté cette organisation des fichiers et les utilisateurs ont vraiment toutà gagneràyadhérer. Le documentexpli- quantcette structure n’est vraimentpaslong.De plus,salecture devient vraiment trèsrapide si l’on ne s’attarde pastrop sur l’exposé desraisons deteloutelchoix effectué par le groupe detravailayantconçu cette organisation.Enfin, le cadre pro- posé donne une certaineliberté àl’utilisateuret le documentexpliqueles choix possibles quipeuvents’offrir.On peutnoteren particulier le problème de savoirs’il faut ou non mettre tel ou tel fichier dans l’arborescence principale ou une arbores- cencelocale.Ce documenta donc en plusle mérite defaireréfléchir l’utilisateursur des points qu’il aurait sans doute ignoré autrement.

Le dernierproblème étaitque ce documentestécriten anglais etcertains utilisateurs francophones pouvaient trouver là une excuse pour faire n’importe quoisur leur système. Avec cette traduction, cette excuse n’est plus valable !

1 Introduction

TEXestun système de composition puissantet flexible utilisé parde nombreuses personnes dansle monde. Ilest facilementportable et tourne quasimentsur tous les systèmes d’exploitation.Un effetde bord malheureuxdelaflexibilité deTEX estqu’iln’ya pas une seule«bonne» façon del’installer.Cela a donnélieu à de nombreuxsites ayantdes schémas d’installation différents. Le butpremierde ce documentestde décrire une structure derépertoiresTEXstandard(TEXDirectory Structure,abrégé désormais enTDS) :une hiérarchie derépertoires pour les macros, lesfontes et les autresfichiers dépendants del’implantation du systèmeTEX.En ce quiconcernele côté pratique,ce documentsuggère égalementdesfaçons d’ajouter lereste desfichiers dans une seule structure. LaTDS a été pensée pourpouvoir fonctionnersur tousles systèmes modernes.En particulier, le groupe detravail technique(TechnicalWorkingGroup: TWG)estime qu’elle estutilisable sous MacOS, MS-DOS, OS/2, Unix, VMS et Windows NT. Nous espérons que les administrateurs et les développeurs des distributionslibres ou commerciales deTEXadopterontce standard.Ce documentestprévu àlafois pour l’administrateursystème d’un site et pour les personnes préparantdes distributionsTEX –detoutde ce quiestnécessaire à un système complet fonctionnel jusqu’à une unique macro oufichierde style. Il peutégalementaider les utilisateurs deTEXàtrouver leurchemin àl’intérieurdes systèmes organisés de cettefaçon. Ilne s’agitpas d’untutoriel :nous supposons nécessairementune connaissance de plusieurs parties d’un systèmeTEX fonctionnel.

Si vous n’êtes pasfamilieravecles programmes et lesfichiers auxquels nous nous référons, consultez les documents cités à l’annexe D.

1.1 Historique

Laversion1.0delaTDS estsortie enfévrier2003. Laversion1.1estsortie enjuin 2004 avec les modifications suivantes :

– les sources des packages deTEXsont inclus danstex^,aulieu d’être placés àla racine de leurs propres sous-répertoires (section 3.1.1) ;

– nouveau répertoire de premier niveauscripts(section 3.6).

– nouveauxsous-répertoireslig^,opentype^,truetype^ettype3^sousfonts^(sec- tion 3.2) ;

– enc^,lig ^et map utilisent tous les sous-répertoires 〈syntaxe〉/〈package〉 (sec- tion 3.2) ;

– les fichierspfmdoivent aller soustype1et les fichiersinfsousafm(section 3.2).

1.2 Rôle de la TDS

Lerôle delaTDS estde stabiliser l’organisation des packageslogiciels du monde TEXquisont installés etutilisés,éventuellementdefaçon simultanée,surplusieurs plates-formes.Àpremièrevue, ilpeutsemblerquele ComprehensiveTEXArchive Network(CTAN) réalise au moins une partie de cerôle mais,enréalité,ce n’estpasle cas. Lerôle du CTAN estde simplifier l’archivage et la distribution,pasl’installation ni l’utilisation.Enréalité, lesrôles delaTDS etdu CTAN sont fréquemmenten conflit comme nousleverrons.Pourune distribution,de nombreux types différents de fichiers doiventêtre combinés en une seule unité.Pour l’utilisation, ilesthabituelde répartir lesfichiers(mêmes desfichiers similaires)provenantd’un unique package dans des répertoires séparés, parfois même très éloignés.

1.3 Conventions

Dans ce document, «/^»estutilisé pourséparer les composants des noms defichiers comme,parexemple,texmf/fonts^{. Ils’agitde}la convention Unixmais cette mé- thode n’est pas spécifique à Unix. Dans ce document, « TEX » signifie généralement le systèmeTEX, ycomprisMETAFONT, les pilotesDVI, les utilitaires,etc.etnon pas seulement le programmeTEXenlui-même. Le mot «package»,dans ce document, a son sens habituel :un ensemble defichiers distribués, installés etmaintenus de façon unitaire.Cen’estpasune extensionLATEXquiestunfichierde style complétant une classe de document.Nous utilisonsles conventionstypographiques suivantes: littéral ^Untextelittéral telquenomfichier^{estcomposé en}fonte non propor-

tionnelle.

〈variable〉 Un texte variable tel que〈package〉, indiquant une classe de choses, est composé en italique à l’intérieur de crochets angulaires.

2 Généralités

Cette section décrit les propriétés communes à toute l’arborescence de la TDS.

2.1 Recherche de sous-répertoires

Lesvieillesinstallations deTEXstockaientun grand nombre defichiers dans un seul répertoire,parexempletouslesfichiersTFM^et/outouslesfichiers sourcesTEX.Cette organisation monolithique rendait plus difficile la maintenance d’un système TEX : ilétaitdifficile de déterminerquelsfichiers étaientutilisés parquels packages,quels fichiers nécessitaientd’être mis àjour lorsqu’une nouvelleversion était installée ou quelsfichiers devaientêtre suppriméslorsqu’un package étaitsupprimé.C’était égalementune source d’erreursideuxpackages ou plus avaientdesfichiers sources ayant le même nom.Pourcetteraison, leTWGa estimé que chaque package devait être dans unrépertoire séparé.Nousreconnaissons cependantqu’uneliste explicite detouslesrépertoires pouvantêtrerecherchés serait invivable.Un site peutsou- haiter installerdes dizaines de packages.De plus,uneliste detouslesrépertoires produiraitdes chemins derecherche de centaines de caractères delong,dépassant l’espace disponible surcertains systèmes.De même,si touslesrépertoires étaient explicitement listés, l’installation oula suppression d’un packageimpliquerait la modification d’un chemin ainsiquel’installation oula suppression desfichiers.Cela serait très consommateurdetemps etproduirait facilementdes erreurs,même avec lesimplantations qui fournissentun moyen de spécifier lesrépertoires en cours d’exécution d’une commande.Sur les systèmes ne disposantpas de cette possibilité derecherche en cours d’exécution, il faudrait recompiler lelogiciel :ce seraitune gêneintolérable.En définitive, leTWGa conclu qu’uneTDS polyvalente nécessitait desimplantations permettantune certaineforme derechercheimplicite de sous- répertoires.Plus précisément, lesimplantations doiventpermettre de spécifierque TEX,METAFONTet leurs utilitaires satellitesrecherchentàlafois dans unréper- toire donné et, récursivement,danstousles sous-répertoires de cerépertoirelors d’unerecherche d’unfichier.D’autres possibilités derecherche de sous-répertoires, parexemple desrecherchesrécursives à un seulniveau,peuventégalementêtre présentes.Nousrecommandons auxconcepteurs de distributions d’indiquer les sous-répertoires derecherches,entantqu’options àl’installation ou en cours d’utili- sation,pour tousles chemins. LaTDS n’impose pas de syntaxe pour la spécification desrecherchesrécursives mais nousrecommandons auxconcepteurs de distribu- tions de penser au côté interactif (voir section B.2).

2.2 Enraciner l’arborescence

Dans ce document,nousindiqueronslerépertoireracine delaTDS par «texmf^» (pour « TEXetMETAFONT^»).Nousrecommandons d’utiliserce nomlorsque c’est possible mais le nom véritable de ce répertoire sera à la charge de celui qui installe.

Sur lesréseauxPC,parexemple,cela peutêtre mappé surune spécification de disquelogiquetelle queT:^.De même, lalocalisation de cerépertoire sur le système sera dépendante du site.Elle peutêtre àlaracine du système defichiers.Sur les systèmes Unix,/usr/local/share^,/usr/local^,/usr/local/lib^ou/opt^sont des choixcourants. Le nomtexmfa été choisipourplusieursraisons: il reflètele faitquelerépertoire contientdesfichiers serapportantà un systèmeTEXentier (y comprisMETAFONT^,METAPOST^,BIBT_E^X,etc.)etpas seulement TEX lui-même; il indique defaçon descriptive qu’ils’agitd’uneinstallation générique plutôtqu’une implantation particulière.Un site peutchoisird’avoirplus d’une hiérarchieTDS installée(parexemple, lors del’installation d’une mise àjour).Cela estparfaitement légitime.

2.3 Ajouts locaux

LaTDS ne peutpas spécifierprécisémentsiun package estou non un«ajout local ».

Chaque site doitdéfinirceterme enfonction de ses propres conventions.Auxdeux extrêmes,un site considérera«nonlocal » tout fichiernefaisantpas partie dela dis- tribution TEX installée alors qu’un autre site considérera « locaux » les seuls fichiers quisonteffectivementdéveloppés sur le sitelocaletquine sontdistribués nulle partailleurs.Nousreconnaissonsles deuxméthodes courantes ci-dessous pour les ajoutslocauxà une arborescencetexmf^{. Les deuxont leurplace et,enfait,certains} sites les emploient de façon simultanée.

1. Une arborescence complètementséparée quiestdonc elle-même une struc- tureTDS.Parexemple/usr/local/umbtex^àl’université du Massachusetts à Boston.C’estun autre exemple des hiérarchiestexmfmultiples mentionnées dans la section précédente.

2. Unrépertoire nommé«local^»à un niveau convenable.Parexemple,dans lesrépertoires〈format〉,〈package〉et〈fournisseur〉étudiés dansles sections suivantes. LaTDSréservele nom derépertoirelocal^{pourcetusage.Nousre-} commandonsl’utilisation delocal^{pour les}fichiers de configuration adaptés au sitetels quelanguage.datpour le package Babelougraphics.cfg^pour le package graphics. Lesfichiers de configuration non modifiés d’un package devraient resterdanslerépertoire de ce package. Le butestde séparer les fichiers créés ou modifiéslocalementdesfichiers dela distribution afin de faciliter les nouvelles mises à jour.

Untâche courante des ajoutslocauxest la production dynamique defichiers,par exemplelesfontes PK par le scriptmktexpk^{(quiprovientde}MakeTeXPK^dansDvips).

Un site peut stocker les fichiers produits directement au niveau de (au choix) : – leurendroitstandard dansl’arborescenceTDS principale(sielle a étérendue

globalement accessible en écriture) ;

– un autre endroitdansl’arborescenceTDS principale(parexemple soustexmf/

fonts/tmp) ;

– une arborescence TDS secondaire complète (comme précisé auparavant) ; – un autre répertoire convenable (peut-être sous/var, par exemple/var/spool/

fonts).

Il n’y a pas de solution unique adaptée à tous les sites.

2.4 Nom de fichiers dupliqués

Plusieursfichiers ayant le même nom peuventexisterdans une arborescenceTDS.

LaTDS ne spécifie généralementpaslequeldes deux fichiers ayant le même nom dans un chemin derecherche seratrouvé;parconséquent,généralement, la seule façon d’être certain de trouver un fichier donné est d’avoir un nom unique. Cepen- dant, la TDS exige que les implantations acceptent les exceptions suivantes : – Les noms desfichiers sourcesTEXdoiventêtre uniques au niveau de chaque

sous-répertoire de premierniveau detexmf/tex^ettexmf/tex/generic^mais pas sur toutel’arborescence detexmf/tex.C’est-à-dire que desformatsTEX différents peuventavoirdesfichiers ayant le même nom(la section 3.1étudiera toutcela plus en détails).De cettefaçon, iln’yaura pas besoin de spécification de chemins dépendants duformat.Parexemple,unerechercherécursive débutant surtexmf/texn’aura pas à spécifierd’autresrépertoires.Ainsi, lesimplantations doivent fournirdes spécifications de chemins dépendants duformat,parexemple via des scripts ou des fichiers de configuration.

– De nombreusesfontes auront le même nom(parexemplecmr10.pk) ; voir la section 3.2.2. Lesimplantations doiventdistinguercesfichiers enregardant le mode et la résolution.

Touteslesimplantations que nous connaissons ontces propriétés. Les endroits où des noms dupliqués sont fréquemment rencontrés ne sont pas exceptionnels.

– Les noms desfichiers sourcesMETAFONT(contrairementà ceuxdesfontes bit- map)doiventêtre uniques àl’intérieurdetexmf/fonts^.En pratique, il ya des problèmes avec certainesvariantes deComputerModernquicontiennentdesfi- chierslégèrementmodifiés appeléspunct.mf^,romanl.mf^{,etainside suite.Nous} croyons quela seule solutionvalide estderenommer lesfichiers dérivés afin de les rendre uniques.

3 Répertoires de premier niveau

Lesrépertoires souslaracinetexmfindiquent les composants majeurs d’un système TEX (voirsection4pourunrécapitulatif ).Un site peutomettretoutsous-répertoire non nécessaire.Bien quelaTDS,parnature,puisse spécifierdes endroits précis seulementpourdesfichiers dépendants del’implantation,nousreconnaissons que ceuxqui installentpeuventsouhaiterplacerd’autresfichiers soustexmfafin de sim- plifier l’administration d’une arborescence TEX, en particulier si elle est maintenue parquelqu’un d’autre quel’administrateursystème.Parconséquent,desrépertoires de premierniveau supplémentaires peuventêtre créés. Lesrépertoires de premier niveau indiqués par la TDS sont :

tex pour les fichiers TEX (section 3.1).

fonts pour les fichiers concernant les fontes (section 3.2).

metafont pour les fichiersMETAFONTqui ne sont pas des fontes (section 3.3).

metapost pour les fichiersMETAPOST(section 3.4).

bibtex pour les fichiers BIBTEX (section 3.5).

scripts pour les exécutables dépendants de la plate-forme (section 3.6).

doc pour la documentation de l’utilisateur (section 3.7).

source pour les sources.Cela comprend àlafoisles programmes sourcestradition- nels(parexemple, les sources de Web2Cvontdanstexmf/source/web2c⁾ et,parexemple, lesfichiers sourcesLATEX.dtx^{qui vontdans}texmf/source/

latex^{. La}TDS ne spécifie aucune structure pour lerépertoire quiestsous source.sourceestdestiné aux fichiers quine sontpas nécessaires àl’exé- cution de n’importe quelprogrammeTEX. Ilne doitêtreinclus dans aucun chemin derecherche.Parexemple,plain.tex^{ne doitpas setrouversous} texmf/source^{,même s’ils’agitbien d’un« fichiersource»dans}le sens qu’il n’estpas produità partird’un autrefichier (il va danstexmf/tex/plain/

basecomme expliqué à la section 3.1).

〈implantation〉 pour les implantations (par exempleemtex,vtex,web2c), devant être utilisées pourn’importe quelbutconsidéré comme adéquatpar la per- sonne ayant réalisél’implantation ou par l’administrateur TEX.En d’autres termes, lesfichiers quine peuventpas être partagés entre plusieursimplan- tations, tels queles fichiers de spool (tex.pool^{)et les} fichiers de dump (plain.fmt^{) vont}à ces endroits,en plus desfichiers de configuration de l’implantation. Voirsection B.3 pourdes exemples d’arbres〈implantation〉 réels.De tels fichiers de configuration spécifiques à l’implantation ne devrait pasêtretrouvés en utilisant le chemin derecherche principaldes sourcesTEX (parexempleTEXINPUTS^{).Cela doitêtre}réservé aux fichiersréellement lus par le compilateur TEX. Voir section 3.1.1.

〈programme〉 pour les sources spécifiques au programme et lesfichiers de configu- ration de n’importe quelprogramme satellite deTEX (parexemplemft^,dvips^).

Enréalité, lesitemstex^,metafont^,metapost^etbibtexci-dessus peuvent toutes être vus comme des instances de ce cas.

3.1 Macros

Les fichiers de macros TEX seront stockés dans des répertoires séparés, en fonction duformat TEXetdu nom de package(nous utilisons« format »avec son sensTEX tra- ditionnelpour indiquerun ensemble précompilé de macros commelatex^,plain^, etc.) :

texmf/tex/〈format〉/〈package〉/

〈format〉 est un nom de format (par exemple :amstex,latex,plain,texinfo).

LaTDS autorisele stockage à n’importe quelniveau des distributions pouvant être utilisées commeformats ou packages(parexemple, Texinfo,Eplain),àla discrétion del’auteurduformatou del’administrateur TEX.Nousrecomman- dons queles packages utilisés entantqueformats surun site donné soient stockés au niveau〈format〉:enréglant le chemin derecherche des sources TEX,on pourra directement les utilisercomme des packages de macros sous d’autresformats,alors queles placerdans une autre arborescence cachera totalement leurutilisation entantqueformat. LaTDSréserveles noms de

〈format〉suivants :

– generic^{,pour les}fichiers sources quisontutiles pourun grand nombre de formats(parexemplenull.tex^,path.sty^).Généralement,cela signifie tout formatutilisant les codes de catégorie de PlainTEXetnonrelié à un format particulier. C’est donc différent des fichiers qui ne sont utilisés que sous PlainTEX (quidevrontêtre placés soustexmf/tex/plain^)comme, par exemple,testfont.texetplain.texlui-même.

– local, pour les ajouts locaux. Voir section 2.3.

Ainsi,pourpresquetouslesformats, ilestnécessaire de chercherau minimum danslerépertoire〈format〉puis danslerépertoiregeneric^{(dans cetordre).}

Les autresrépertoires peuventavoirbesoin d’être examinés également,cela dépendantduformat. Lors del’utilisation d’AMS-TEX, par exemple, les répertoiresamstex^,plain^etgeneric^doiventêtre examinés,carAMS-TEX est compatible avec Plain.

〈package〉 est un nom de package TEX (par exemple :babel,texdraw).

Au cas où unformatseraitconstitué d’un seul fichieretn’auraitaucun package auxiliaire,cefichierpeutêtre simplementplacé danslerépertoire〈format〉au lieu de〈format〉/base^{.Parexemple, T}exinfo peutêtre placé danstexmf/tex/

texinfo/texinfo.tex^{etnon dans}texmf/tex/texinfo/base/texinfo.

tex. La TDS réserve les noms de〈package〉suivant :

– base, pour la distribution de base de chaque format, y compris les fichiers utilisés par iniTEX lors du dumping desfichiers deformat.Parexemple,dans la distributionLATEXstandard, lesfichiers.ltxcréés au cours du processus defabrication.Un autre exemple estceluidesfichiers de pilote.ini^pour les formats utilisés par la TEX Live et d’autres distributions.

– hyphen,pour les motifs de césures, ycomprislefichierde motifs américains hyphen.tex^{d’origine.Ceux-ci}sont typiquementutilisés uniquementpar iniTEX.Dansla plupartdes situations,cerépertoire n’a besoin d’existerque sous le répertoiregeneric.

– images^{,pour les}fichiers sources d’imagestels quelesfigures en PostScript encapsulé. Bien qu’il ne soit pas très intuitif de mettre ces fichiers dans un répertoire nommé«tex^{», T}_E^Xa besoin delire cesfichiers pourobtenir la bounding boxou d’autresinformations.Un mécanisme pourpartager les sources desimages entreTEXetd’autres programmes de composition de texte(parexempleInterleaf,FrameMaker)estau-delà des prérogatives de laTDS.Dansla plupartdes situations,cerépertoire n’a besoin d’existerque sous le formatgeneric.

– local^,pour les ajouts locaux et lesfichiers de configuration. Voirsec- tion 2.3.

– misc^,pour les packages constitués d’un seul fichier.Un administrateuroule mainteneurde ce package peuventcréerdesrépertoires pour les packages à fichier unique à leur convenance au lieu d’utilisermisc.

3.1.1 Extensions

Le moteur TEXa inspiré de nombreuxdéveloppementsvisantà lui trouverdes compagnons ou successeurs,on peutciterPDFTEX,Omega,etc. LaTDSindique que lesfichiers sources de ces programmes(utilisantune syntaxe«àlaTEX »)doiventêtre placés àl’intérieurdurépertoire de premierniveautex^,soitau niveau supérieur, soitdans un sous-répertoire deformat,même si le programme d’origineTEXn’est pas capable de les lire. Par exemple :

texmf/tex/aleph texmf/tex/enctex

Ils’agitd’une modification par rapportàlaTDS1.0quispécifiaitdesrépertoires de premierniveau〈extension〉pourchacun de ces programmes.Nous considérons que cette nouvelle approche est préférable car :

– Les auteurs de packages sensibles au moteurpermettentsouventàleurcode de détecter le moteurentrain d’être utilisé en émettantdes messages d’erreurou en s’adaptant au circonstances de façon appropriée.De plus, lors de sa maturation,

un package peuts’adapterà un nombre croissantde moteurs.Ainsi, ilestconce- vable qu’un package puisse être placé dans chacun des multiplesrépertoires de premierniveau à différents moments.Mettretous ces packages souslerépertoire de premier niveautexdonne un endroit stable au cours du temps.

– Les utilisateurs on besoin de pouvoirutiliserplusieurs moteurs et la configuration de différents chemins de recherche pour chaque moteur serait difficile et sujette à erreurs.

En pratique,avoirdifférentsrépertoires de premierniveau entraînaitdes difficultés pour toutesles personnes concernées–utilisateurs,auteurs de packages,adminis- trateurs de site etdistributeurs de systèmes.Prenez soin de comparercette approche avecle sous-répertoire de premierniveau〈implantation〉(section 3)quidevaitêtre utilisé pour lesfichiers de configuration qui (sans doute)n’utilisaientpasla syntaxe TEXet,entous cas,ne devaitpas êtretrouvé par le chemin derecherche principal des sources TEX.

3.2 Fontes

Les fichiers de fontes sont stockés dans des répertoires séparés, classés par type de fichierpuis(dansla plupartdes cas)par fournisseuretpar famille. Lesfichiers PK et GF ontbesoin d’une structure supplémentaire,ce que nousverrons en détaildans la prochaine section.

texmf/fonts/〈type〉/〈fournisseur〉/〈famille〉/ texmf/fonts/enc,lig,map/〈sousrepertoire〉/

〈type〉 est letype delafonte. LaTDSréserveles noms de〈type〉suivantpour les types de fichiers habituels de TEX :

– afm, pour les fichiers de métriques Adobe et les fichiersinf; – gf, pour les fichiers de fontes générique (generic font) bitmap.

– opentype, pour les fontes OpenType ;

– pk, pour les fichiers bitmap compressé (packed bitmap) ;

– source^{,pour les}fichiers sources defontes(fichiersMETAFONT, listes de propriétés (property lists), etc.).

– tfm, pour les fichiers de métriques de fontes (TEX font metric) ; – truetype, pour les fontes TrueType ;

– type1^{,pour les}fontes PostScript Type1 (danspfa^,pfb^{outoutautrefor-} mat) et les fichierspfm;

– type3, pour les fontes PostScript Type 3 ; – vf, pour les fontes virtuelles (virtual fonts).

LaTDSréserve également les nomsenc^,lig^etmappour, respectivement, le codage desfontes, lesligatures et lesfichiers de map. Tous cesrépertoires sontstructurés dela mêmefaçon avec des sous-répertoires〈syntaxe〉puis

des sous-sous-répertoires〈package〉.Chacun de cestypes defichiers sera recherché avec son propre chemin derechercherécursive.Comme d’habitude, les noms desfichiers effectifs doiventêtre uniques àl’intérieurdeleursous- arbre. Exemples :

fonts/map/dvipdfm/updmap/dvipdfm.map fonts/map/dvips/lm/lm.map

fonts/enc/dvips/base/8r.enc

Les packages Fontname etDvips ontplus d’exemples detypesenc^etmap^{. Le} programmeafm2plutilise desfichierslig. Lesfichierspfmsont inclus dans lerépertoiretype1^aulieu d’être placés dansleurs propresrépertoires pour deux raison: 1)unfichier.pfmest toujours un supplémentd’unfichier.pfb donné;2) ils doiventêtreinstallés depuisle mêmerépertoire pourque des programmes Windows autres queTEXpuissent les utiliser. Lesfichiersinf sontplacés danslerépertoireafm^{puisquelesfichiers}inf^etafm^peuvent être utilisés pourproduire unpfm(malheureusement,AdobeType Manager, etpeut-être d’autreslogiciels,demande quelesfichierspfb^soientdansle mêmerépertoire quelesfichiersafm^etinfpour leur installation).Comme d’habitude,un site peutomettre n’importelequelde cesrépertoires dansla mesure oùils ne serventpas. Lerépertoiregf^estun bon candidatpourune telle omission.

〈fournisseur〉 estun nomidentifiant le source delafonte(exemples:adobe^,ams^, public). La TDS réserve les noms de〈fournisseur〉suivant :

– ams^,pour la bibliothèque defontesAMS-fonts del’American Mathemati- cal Society .

– local, pour les ajouts locaux. Voir section 2.3.

– public,pour lesfonteslibrement redistribuables oùlefournisseur : (1)ne demande pas son proprerépertoire(parexempleams^{) ; (2)ne}fabrique pas defontes propriétaires(parexempleadobe^{). Il}ne contientpastoutesles fonteslibrementdistribuables en circulation et lesfichiers placés à son niveau ne sont pas nécessairement strictement du domaine public.

– tmp^{,pour les}fontes produites defaçon dynamique comme c’est l’habitude sur certains systèmes. Il peut être omis s’il n’est pas utile.

〈famille〉 est le nom delafamille defontes(exemples:cm^,euler^,times^{). LaTDS} réserve les noms de〈famille〉suivants :

– cm(au niveau depublic^{),pour les}75 fontes définies dansComputers and Typesetting, Volume E.

– latex(au niveau depublic^{),pour les}fontes distribuées avecLATEXdans une distribution de base.

– local, pour les ajouts locaux. Voir section 2.3.

Voici quelques exemples :

texmf/fonts/source/public/pandora/pnr10.mf texmf/fonts/tfm/public/cm/cmr10.tfm

texmf/fonts/type1/adobe/utopia/putr.pfa

Pouruneliste complète des noms defournisseurs etdefamilles,on consultera Filenames for TEX fonts(voir annexe D).

3.2.1 Fontes bitmap

Lesfichiers defontes bitmap nécessitentdeuxcaractérisations en plus de celles indiquées précédemmentpourêtreidentifiables defaçon unique: (1) letype du périphérique(c’est-à-direle mode)pour lequel lafonte a été créée; (2) larésolution du bitmap.Suivanten cela une pratique courante, laTDSrépartit lesfontes sous dif- férentsrépertoires enfonction des différentstypes de périphériques. Voirmodes.mf àl’annexeDpour lesrecommandations des noms de modes.Certainesimprimantes ontplusieursrésolutions possibles(parexemple 300dpiet600dpi)mais chaque résolution nécessitera un nom de mode différent.Rien de plus n’estnécessaire puisque,dansTEX, ilest implicitementsupposé qu’iln’ya qu’une uniquerésolution possible.Deux types de nomenclatures sontcourammentutilisés pour identifier la résolution desfichiers defontes bitmap.Sur les systèmes quiadmettent les noms de fichierslongs(etpour le programme d’origineMETAFONTlui-même), larésolution est incluse dansle nom defichier (parexemplecmr10.300pk^).Sur les systèmes qui ne supportentpasles noms defichierslongs, lesfontes sontgénéralement réparties enrépertoires suivant leursrésolutions(parexempledpi300/cmr10.pk^).Comme laTDS ne peutpas exiger les noms defichierslongs,nous devons utiliser le second schéma pourdénommer lesfontes.Ainsi,nous aurons deuxniveau supplémentaires de sous-répertoires souspketgf:

texmf/fonts/pk/〈mode〉/〈fournisseur〉/〈famille〉/dpi〈nnn〉/ texmf/fonts/gf/〈mode〉/〈fournisseur〉/〈famille〉/dpi〈nnn〉/

〈mode〉 estun nom par lequelonidentifieletype de périphérique(parexemple: cx^,ljfour^,modeless^).Normalement, ils’agitdu nom du modeMETAFONT utilisé pourconstruirelesfichiers PK.Pour lesfontes bitmap produites parun programme quine distingueraitpas ces différentstypes de périphériques, le

〈mode〉sera simplementmodeless. Le niveau〈mode〉ne doitpas être omis, même s’il n’y a qu’un seul mode qui sera effectivement utilisé.

dpi〈nnn〉 spécifie la résolution de la fonte (par exemple :dpi300^,dpi329^{). «}dpi^» signifie«dots per inch»,c’est-à-dire pixels parpouce.Nous sommes conscient que dans de nombreuxpaysles pixels parmillimètre sontutilisés maisl’unité dpiest trop ancrée dansle mondeTEXpourque nous pensions en changer maintenant.

L’entier〈nnn〉doitêtre calculé comme si l’on utilisait l’arithmétique et l’ar- rondiMETAFONT^,c’est-à-dire comme s’ils’agissaitdel’entierutilisé par METAFONT^{dans sonfichierde sortie}gf^.Nousreconnaissons cependant que de petites différences au niveau delarésolution sontune causefréquente defrustration pour les utilisateurs etnousrecommandons auxconcepteurs de suivrele standard du piloteDVIniveau0 (voirannexeD)pour larecherche defontes bitmap en autorisantun écartde±0,2% (avec un minimum de1) au niveau du〈dpi〉.

Lesimplantations peuvent fournirdes extensions à ce schéma de base pour les noms, telles queles noms defichierslongs(comme dansleMETAFONT^d’origine) oulesfichiers de bibliothèque defontes(comme danslesfichiers.fli^{de emT}_E^X), dans la mesure où le schéma de base sera également supporté.

3.2.2 Noms de fontes bitmap valides

LeTWGa conscience quel’utilisation des noms defichiers courts a de nombreux désavantages. Le plusvexantestque cela entraînela création de dizaines defichiers différents ayant le même nom.Surun sitetypique,cmr10.pk^{serale nom defichier} pour le ComputerModern Roman10ptsous5à10échelles différentes etpour2 ou 3 modes différents(on sereportera àla section 2.4quiétudiera defaçon géné- rale ce problème de duplication de noms de fichiers). Pour minimiser le problème, nousrecommandons chaudementquelesfichiers PK contiennentsuffisamment d’informations pour identifierprécisément lafaçon dont ils ontété créés:au moins le mode, larésolution de base et l’échelle utilisée pourcréer lafonte.Cetteinfor- mation est facile à obtenir :un simple ajoutdansles modeslocauxutilisés pour la production desfontes avecMETAFONTfournira automatiquement l’information requise.Si l’on a utilisé unfichierde modeslocauxdérivé de(ou quiestsimplement) modes.mf^(voirannexeD), l’informationrequise estdéjà danslesfichiers PK.Sinon, ilsuffitd’effectuerun simple ajoutau niveau desfichiers de modeslocaux,en se basant sur le code trouvé dansmodes.mf, puis de reconstruire les fichiers PK.

3.3 Fichiers

METAFONT

La plupartdesfichiers sources deMETAFONT^sontdes programmes defontes ou des parties de programmes defontes et ils ontété couverts par la section précédente.

Cependant,un petitnombre defichiers n’étantpas desfichiers sources defontes existent. Ces fichiers seront stockés dans :

texmf/metafont/〈package〉/

〈package〉étant le nom d’un packageMETAFONT^(parexemple,mfpic^{). LaTDS} réserve les noms de〈package〉suivants :

– base^{,pour les}fichiers de macrosMETAFONT^{de base,}décrits dansTheMETA^- FONTbook, tels queplain.mfetexpr.mf.

– local, pour les ajouts locaux. Voir section 2.3.

– misc^,pour les packagesMETAFONTconstitués seulementd’unfichierunique (par exemple,modes.mf^). Un administrateur ou un mainteneur de package peuventcréerdesrépertoires pourdes packages ayantun seul fichieràleurdis- crétion au lieu d’utilisermisc.

3.4

METAPOST

METAPOST^{estunlangage de}tracé graphique développé par John Hobbyetqui estdérivé duMETAFONT^{de Knuth.Son butprincipalest}de produire du Post- Scriptencapsulé aulieu defontes bitmap. Lesfichiers sources deMETAPOST^{et les} fichiers concernant les utilitaires satellites deMETAPOSTseront stockés dans :

texmf/metapost/〈package〉/

〈package〉étant le nom d’un packageMETAPOST^.Àl’heure actuelle,aucun n’existe maisleTWGpense qu’ilestprudentdelaisserdela place pour les packages pouvant être écrits à l’avenir. La TDS réserve les noms de〈package〉suivants :

– base^{, pour les} fichiers de macros METAPOST ^{de base tels que} plain.mp^, mfplain.mp^,boxes.mp^etgraph.mp^{.Celainclut les}fichiers utilisés par iniMP lors d’un dumping mémoire desfichiers contenantdes définitions de macros pré-chargées.

– local, pour les ajouts locaux. Voir section 2.3.

– misc^,pour les packagesMETAPOSTconstitués d’un seul fichier.Un adminis- trateurou un mainteneurde package peuventcréerdesrépertoires pourdes packages ayant un seul fichier à leur discrétion au lieu d’utilisermisc.

– support^{,pour les}fichiers sources supplémentaires exigés par les programmes satellites deMETAPOST^{,ce quicomprendlesfichiers}.map^{desfontes,untableau} d’ajustementde caractères etun sous-répertoire contenant les programmes de bas niveauMETAPOSTpour le rendu de certains caractères spéciaux.

3.5 BIBTEX

Les fichiers en rapport avec B^IBTEX seront stockés dans : texmf/bibtex/bib/〈package〉/

texmf/bibtex/bst/〈package〉/

Lerépertoirebib^estdestiné aux fichiers de bases de données BIBTEX (.bib^{)et le} répertoirebstaux fichiers de style(.bst^).〈package〉est le nom d’un package BIBTEX.

LaTDSréserveles noms de〈package〉suivants(les mêmes noms sont réservés sous bibetbst) :

– base, pour les fichiers de bases de données et les styles standard BIBTEX tels que xampl.bibetplain.bst.

– local, pour les ajouts locaux. Voir section 2.3.

– misc^,pour les packages BIBTEXconstitués seulementd’unfichierunique.Un administrateurou un mainteneurde package peuventcréerdesrépertoires pour des packages ayant un seul fichier à leur discrétion au lieu d’utilisermisc. 3.6 Scripts

Lerépertoire de premierniveauscripts^estdestiné auxexécutablesindépendants du systèmetels que Perl,Python oules scripts shellainsique pour lesfichiers de classeJava. Les sous-répertoires descripts^sontdes noms de packages.Celafa- cilitela création des distributions enfournissantun endroitcommun pourdetels programmesindépendants dela plate-forme. Le butn’estpas d’ajouter tous ces sous-répertoires à une commande derecherche de sous-répertoires d’un utilisa- teur,ce quiseraitpratiquement impossible à gérer. Ils’agitplutôtd’ymettre des exécutables prévusinitialementpourdes scripts d’appelqu’une distribution pourra utiliserà partirde n’importe quel répertoire(etquin’estpas spécifié par laTDS).De véritables scripts auxiliaires,plutôtqueles scripts d’appel,quiserontexécutés direc- tementpard’autres programmes peuventégalementêtre placés à ce niveau.Cela étant,scripts^{sertégalement}comme une plate-formeindépendantetoutcomme lerépertoire standardlibexec^{sous Unix.Nous}recommandonsl’utilisation d’exten- sions précisant lelangage(telles que.pl^,.py^,.sh^{)pourcesfichiers,uniquement} pourmieux identifier leurs noms.Commele butdelaTDS concernant lerépertoire scripts^{estd’yplacer}des programmes ne devantpas être appelés directement par l’utilisateur,cela ne pose aucun problème.Parexemple,dansla distribution TEX Live, le programme ConTEXttexexec^,exécutable directementpar l’utilisateur, peutexisterentantque petitscriptd’appeldans chaquerépertoirebin/〈plate- forme〉/texexec ^{(qui sont} en dehors de l’arborescence texmf^), ce dernier ira toutsimplement trouveret lancertexmf/scripts/context/perl/texexec.pl^. Exemples :

scripts/context/perl/texexec.pl scripts/context/ruby/examplex.rb scripts/thumbpdf/thumbpdf.pl

LaTDS ne spécifie pas d’emplacementpour les binaires exécutables dépendants de la plate-forme, qu’ils soient destinés directement ou non à l’utilisateur.

3.7 Documentation

La plupartdes packages sontdisponibles avec un certaintype de documentation: manueldel’utilisateur, fichiers d’exemples,guide du programmeur,etc.De plus,

beaucoup defichiersindépendants nefaisantpas partie de packages ontété créés pourdécrire des aspectsvariés du systèmeTEX. LaTDSindique que cesfichiers de documentation supplémentaires serontstockés dans une structure parallèle, jusqu’à une certaine profondeur, aux répertoiresfontsettexcomme décrit ci-dessous :

texmf/doc/〈catégorie〉/...

〈catégorie〉indiquele sujetgénéraldela documentation quiestplacé sous ce niveau.

Parexemple,un nom deformat TEX (latex^),un nom de programme(bibtex^,tex^), un nom delangue(french^,german^{),unformatdefichier (}info^,man⁾ou d’autres composants du système(web^,fonts^).Une disposition possible estd’organiserdoc par langue,avectousles autrestypes de catégories au-dessous.Cela aiderales utilisateurs àtrouverdela documentation dansla ouleslangues aveclesquellesil se sententplus àl’aise.Nicettefaçon defaire niaucune autre,bien sûr,n’estexigée.

Àl’intérieurde chaque arborescence〈catégorie〉d’unformat TEX, lerépertoirebase est réservé pour la documentation de base distribuée par les mainteneurs duformat.

La TDS réserve les noms de catégories suivants :

– general^,pour les documentsindépendants,non spécifiques à un programme particulier (par exempleComponents of TEXde Joachim Schrod).

– help, pour les méta-informations, telles que les FAQ’s, le Catalogue TEX, etc.

– info^,pour les documentstraités par Texinfo. LesfichiersInfo,comme n’importe quels autres,peuventégalementêtre stockés en dehors del’arborescenceTDS avec une option lors de l’installation.

– local, pour les ajouts locaux. Voir section 2.3.

Lerépertoiredoc^estprévu pour lesfichiers de documentationindépendants de l’implantation etdu système. Lesfichiers dépendants del’implantation devraient être stockés ailleurs,commel’implantation oul’administrateur TEX l’indique(par exemple, lesfichiers d’aide sousVMS sontplacés soustexmf/vms/help^{). Lesré-} pertoires de documentation peuventcontenirdes sourcesTEX,desfichiersDVI,des fichiers PostScript,desfichierstextes,des exemples defichiers sources ou n’importe quels autresformats utiles de documentation. Voirsection4.1pourunrécapitulatif.

4 Récapitulatif

Voiciun squelette d’une arborescenceTDS derépertoiretexmf^.Cela n’implique pas qu’iln’yaitque ces entrées de permises.Parexemple,unlocal^peutêtre placé à n’importe quel niveau.

bibtex/ fichiers sources BIBTEX

bib/ bases de données BIBTEX

base/ distribution de base (ex :xampl.bib)

misc/ bases de données constituées d’un seul fichier

〈package〉/ nom de package

bst/ fichiers de style B^IBTEX

base/ distribution de base (ex :plain.bst,acm.bst) misc/ styles constitués d’un seul fichier

〈package〉/ nom de package

doc/ voir section 3.7 et le récapitulatif ci-dessous fonts/ fichiers en rapport avec les fontes

〈type〉/ type de fichier (ex :pk)

〈mode〉/ type de périphérique de sortie (pourpketgf)

〈fournisseur〉/ nom d’un fournisseur de fontes (ex :public)

〈famille〉/ nom d’une famille (ex :cm)

dpi〈nnn〉/ résolution de fontes (seulement pourpketgf)

〈implantation〉/ implantations TEX par nom (ex :emtex) local/ fichiers créés ou modifiés sur le site local metafont/ fichiers sourcesMETAFONT(hors fontes)

base/ distribution de base (ex :plain.mf)

misc/ packages constitués d’un seul fichier (ex :modes.mf)

〈package〉/ nom d’un package (ex :mfpic)

metapost/ fichiers sources et satelliteMETAPOST base/ distribution de base (ex :plain.mp) misc/ packages constitués d’un seul fichier

〈package〉/ nom d’un package

support/ fichiers pour les utilitaires liés àMETAPOST

mft/ sourcesMFT(ex :plain.mft)

〈programme〉/ programmes satellites de TEX, par nom (ex :dvips) source/ code source de programmes (ex :latex,web2c)

tex/ fichiers sources TEX

〈moteur〉/ nom d’un moteur (ex :aleph) ; éventuellement plus bas

〈format〉/ nom d’un format (ex :plain)

base/ distribution de base d’un format (ex :plain.tex) misc/ packages constitués d’un seul fichier (ex :webmac.tex) local/ ajouts locaux ou fichiers de config. pour un〈format〉

〈package〉/ nom d’un package (ex :graphics,mfnfss) generic/ packages indépendants du format

hyphen/ motifs de césures (ex :hyphen.tex)

images/ fichiers sources graphique (ex : PostScript encapsulé) misc/ packages indépendants du format à fichier unique

〈package〉/ nom d’un package (ex :babel)

4.1 Récapitulatif de l’arborescence de la documentation

Voiciun exemple de squelette d’une arborescence derépertoiresTDS soustexmf/

doc^.Cela n’implique pas qu’iln’yaitque ces entrées de permises nique cette struc- ture doitsuivre exactementce quiestprésenté ci-dessous.Commeindiqué précé- demment, l’arborescencetexmf/doc^peutêtre organisée par langue.De cettefaçon, toutela documentation enfrançais,disons,sera placée dans un sous-répertoire french^.Dans ce cas, l’exemple de structure donnée ci-dessous sera celle placée au niveau du sous-répertoire donné d’une langue.

ams/amsfonts/ amsfonts.faq,amfndoc amslatex/ amslatex.faq,amsldoc amstex/ amsguide,joyerr bibtex/ BIBTEX

base/ btxdoc.tex fonts/

fontname/ Filenames for TEX fonts oldgerm/ corkpapr

〈format〉/ nom d’un format TEX (ex :generic,latex) base/ pour la distribution de base

misc/ pour les contributions constituées d’un seul fichier

〈package〉/ pourpackage

general/ tour des programmes, généralités errata/ errata,errata[1-8]

texcomp/ Components of TEX help/ méta-information

ctan/ informations sur les sites miroirs CTAN faq/ FAQs decomp.text.tex, etc.

info/ fichiers GNU Info, réalisés à partir de sources Texinfo latex/ exemple de〈format〉

base/ ltnews*,*guide, etc.

graphics/ grfguide

local/ documentation spécifique au site

man/ pages de man Unix

〈programme〉/ programmes du monde TEX, classés par nom metafont/ mfbook.tex,metafont-for-beginners, etc.

metapost/ mpman,manfig, etc.

tex/ texbook.tex,A Gentle Introduction to TEX, etc.

web/ webman,cwebman

A Points non spécifiés

La TDS ne peut pas s’occuper des aspects suivants d’un système TEX fonctionnel : 1. L’emplacementdes programmes exécutables:c’est trop dépendantdu site

pourpouvoir recommanderun endroit,encore moinsl’exiger.Un site peut placer les exécutables en dehors del’arborescencetexmf^(parexemple dans /usr/local/bin^),au niveau d’unrépertoire dépendantdela plate-forme à l’intérieur detexmfou n’importe où ailleurs.

2. Les packages mis àjour lorsque de nouvellesversions sont réalisées:nous ne pouvons trouver aucune façon d’introduire des spécifications de versions danstexmfqui feraientplus de bien que de malou quiseraientadaptées àla plupart des installations.

3. L’emplacementdesfichiers spécifiques àl’implantation(parexemplelesfi- chiersTEX.fmt^{) :par}nature, ils doiventêtrelaissés àla discrétion de ceuxqui implantent ou maintiennent TEX. Voir section B.3.

4. Ce quidoitêtre précisémentconsidéré comme« local »etoù detelsfichiers locaux doivent être installés. Voir section 2.3 pour plus de détails.

A.1 Noms de fichiers portables

LaTDS ne peutpas exiger une quelconquerestriction sur les noms defichiers dansl’arborescence puisqueles noms de beaucoup defichiersTEXexistants ne se conformentà aucun schéma standard.Pour le bien des personnesvoulant réaliser une distribution ou uneinstallationTEXportable,cependant,nous soulignonsici certainesrestrictions nécessaires. Les spécifications delaTDS elles-mêmes sont compatibles avec celles-ci. La normeISO-9660est le seulsystème deformatde fichiers universellementaccepté pour les CD-ROM.Un sous-ensemble deslimita- tionsindiquées estpartagé par tousles systèmes d’exploitation utilisé de nosjours. Cette norme spécifie que :

– les noms defichiers etderépertoires,non comprisle chemin derépertoire et l’extension, ne doit pas dépasser huit caractères ;

– les noms defichiers ne peuventavoirqu’une seule extension etcelle-cine doit pas dépasser trois caractères; les noms derépertoires ne peuventpas avoird’ex- tension ;

– les noms etextensions sontconstituésuniquementdes caractèresA^–Z^,0^–9^etdu caractère underscore ; les lettres minuscules sont exclues ;

– un point sépare le nom de fichier de son extension et est toujours présent même si le nom ou l’extension est vide (exemples :FILENAME.ou.EXT).

– un numéro deversion,dansl’intervalle1–32767,estajouté àl’extension dufichier, séparé de celle-ci par un point-virgule (par exempleFILENAME.EXT;1).

– seuls huitniveauxderépertoires sontpermis,en comptant lerépertoire de plus hautniveau(répertoire de montage). Voirsection 2.2.Ainsi, le cheminISO-9660 le plus profond valide est :

texmf/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1

1 2 3 4 5 6 7 8

Le chemin le plus profond de la TDS ne demande que sept niveaux : texmf/fonts/pk/cx/public/cm/dpi300/cmr10.pk

1 2 3 4 5 6 7

Certains systèmes affichentunformatmodifié des nomsISO-9660, faisantcorres- pondreles caractères alphabétiques avecleursversions minuscules,supprimant le numéro deversion et les points situés auxextrémités,etc.Avant laversion de décembre1996, LATEXutilisaitdes noms avec un mélange de casse pour lesfichiers de description defontes.Heureusement, la non distinction de cette casse n’ajamais entraîné de confusions entrefichiers.Quoiqu’ilen soit, ilutilise maintenantdes noms avec une seule casse.

B Problèmes d’implantation

Nous croyons quelaTDS peutapporterbeaucoup d’ordre àl’état vraimentanar- chique de beaucoup d’installationsTEX.De plus,enindiquantun schéma commun deréférence, il faciliteralestâches ennuyeuses dela documentation administrative.

Enfin, ils’agitd’une partie nécessaire detoutsystèmeraisonnable permettantune véritable automatisation des distributions de packages pour TEX.

B.1 Adoption de la TDS

[Cette section n’estconservée que pourdesraisons historiques: laTDS estmain- tenantassez solidementenracinée dansla plupartdes distributionsTEX.]Nous reconnaissons quel’adoption delaTDS ne sera pasimmédiate etuniverselle.De nombreuxadministrateursTEXne serontpas enclin à effectuer le pas décisif tant que :

– des bénéfices clairs et démontrables ne seront pas visibles pour la TDS ;

– desversions compatiblesTDS detousles programmes clés ne serontpas dispo- nibles et bien testés ;

– une période de«stabilité»n’aura pas pris place en ayantévacuéles problèmes.

Laversion publique du premierbrouillon a étéla première étape de ce processus.

En conséquence, la plupartdes premiers essais delaTDS ontétéréalisés pardes membres dela commissionTDS oules développeurs delogiciels satellites deTEX.

Ceux-ciontdéjà pris place au cours de nos délibérations(voirannexeDpourun exemple d’arbre disponible par le net).Ces essais ontproduits certainementun nombre substantielde packages compatibles aveclaTDS.Enfait, les distributions teTEXet TEX Live sontcompatibles aveclaTDS etsontmaintenantutilisées surde nombreux sites. Une fois que des formes prêtes à installer de packages clés compa- tibles aveclaTDS serontplusrépandues,certains administrateursTEX rendront leur arborescence compatible aveclaTDS,éventuellementen gardanten parallèleles répertoires de production déjà existants.Cestests permettrontsans doute defaire surgirdes problèmes qu’iln’étaitpas évidentde suspecterdansle cadre confiné des sites de développement.Parexemple,cela devraitpermettre derésoudre des dé- pendances de systèmes et de packages, d’interdépendance de packages et d’autres détails nonformulés parcetteversion delaTDS.Après quetoutela poussière sera retombée,espérons que mêmeles plus conservateurs des administrateursTEXcom- mencerontà adopter laTDS.Éventuellement, la plupartdes sitesTEXaurontadopté cette structure commune et la plupartdes packages serontaccessibles sous une forme compatible aveclaTDS.Nous croyons que ce processus arriverarelative- ment vite. Le comitéTDS couvre unlarge spectre d’intérêts dansla communauté TEX.En conséquence,nous croyons quela plupartdes questions clésimpliquées dansla définition d’uneTDSfonctionnelle ontété couvertes,souventen détail. Les développeursTEXontété consultés au sujetdes problèmes d’implantation etont essayéla structureTDS.Ainsi,nous espérons n’avoirque peu de surpriseslorsque l’implantation sera mature.enfin, il ya plusieurs(actuellementou danslefutur)édi- teurs deTEXsurCD-ROM etceux-cisont très motivés pour travaillersur les détails d’implantation delaTDS. Leurs productionsfournissentdesfaçons bon marché et commodes, pour les administrateurs TEX ayant le goût de l’expérience, d’essayer la TDS.

B.2 Compléments sur la recherche de sous-répertoires

Larechercherécursive de sous-répertoires est la possibilité de spécifier unere- cherche non seulementsurunrépertoire donné〈r〉maisrécursivementsur tousles répertoires situés sous〈r〉.PuisquelaTDSindique des emplacementprécis pour la plupartdesfichiers,sans aucun niveau derépertoire supplémentaire permis,une véritablerechercherécursive n’est,enfait,pas exigée pouruneimplantation compa- tibleTDS. Toutefois,nousrecommandonsfortement larechercherécursive comme

étant l’approchela plus soucieuse du confortdel’utilisateuret la plus naturelle plutôtque des méthodestortueuses pourspécifier les chemins sansrécursion.Cette propriété estdéjà supportée parbeaucoup d’implantations deTEXet les utilitaires compagnons commeDECUSTEXpour VMS,Dvips(k),emTEX (etses pilotes),Pu- bliCTEX,Web2C, Xdvi(k)et Y&YTEX. La bibliothèque Kpathsea estuneimplantation réutilisable delarecherche de sous-répertoires pour TEX,exploitée parun grand nombre des programmes précédemmentcités.Même si votreimplantationTEXne supporte pas directement larecherche de sous-répertoires, vous pouveztrouver utile d’adopter la structure si vous n’utilisez pas beaucoup defontes etde packages.

Parexemple,si vous utilisez uniquementComputerModern et lesfontesAMS, il est facile deles stockerdans une structureTDS etdelister lesrépertoires defaçon individuelle dans desfichiers de configuration ou desvariables d’environnement.

Le TWGreconnaît que la recherche de sous-répertoires est une charge supplémen- taire pour le système etqu’elle peutêtrela source d’une baisse de performance, particulièrementsurdes machineslentes.Quoiqu’ilen soit,nous estimons quela recherche de sous-répertoires est impérative pour une TDS bien organisée à cause desraisons évoquées àla section 2.1. Les personnesréalisantdesimplantations sont donc encouragées àfournirdes améliorations au principe de base delarecherche de sous-répertoires afin d’éviterces problèmes de performance,parexemplel’utili- sation de cache pour les noms defichiers(cela peutêtre aussisimple qu’unlisting récursifderépertoires)quisera consulté avantquelarecherche surdisque ne dé- bute.Siune correspondance est trouvée dans cette base de données, larecherche de sous-répertoires n’est plus utile et les performances seront alors indépendantes du nombre de sous-répertoires présents sur le système.Différentesimplantations spécifient larecherche de sous-répertoires différemment.Pourplus de clarté, les exemples qui suivent n’utiliseront pas la fonte〈variable〉.

Dvips : via une variable d’environnementTEXFONTS_SUBDIRséparée.

emTEX : t:\subdir!!;t:\subdir!pour un unique niveau de recherche.

Kpathsea : texmf/subdir//

VMS : texmf:[subdir...]

Xdvi (patchlevel 20) : texmf/subdir/**^;texmf/subdir/* ^pour un unique ni- veau de recherche. Les versions 20.50 et suivantes acceptent la notation//. Y&Y TEX : t:/subdir//out:\subdir\\.

B.3 Exemples d’arborescences spécifiques à l’implantation

LaTDS ne peutpas spécifierd’emplacements précis pour lesfichiers spécifiques à l’implantation tels quetexmf/inicar un site peut avoir plusieurs implantations TEX.Cependant,pour information,nous donnonsici les emplacements pardéfaut pourcertainesimplantations.Nous apprécierons quevous nous contactiez pour

touteinformation supplémentaire ou correction.Ces chemins ne sontpas définitifs, peuventne correspondre àrien sur votre site etêtre modifiés sans avertissements.

Nousrecommandons quetouteslesimplantations aientdes chemins derecherche pardéfautquicommencentaveclerépertoire courant (parexemple«.^{»).Permettre} auxutilisateurs d’inclurelerépertoire parent (parexemple«..^»)sera également utile.

B.3.1 AmiWeb2c 2.0

Vous pouvez écrire àl’adressescherer@physik.rwth-aachen.de^{pour contac-} ter le mainteneurde cetteimplantation.AmiWeb2c 2 estcompatible avec Web2c 7danstoutela mesure du possible etseulesles quelques différences serontdé- crites dans cette section.Uneinformation détaillée sur les concepts de base est donnée dansla section surWeb2c un peu plusloin.Grâce au mécanismeSELFAUTO de Kpathsea 3.0,aucun emplacementspécifique pour l’installation d’AmiWeb2c n’estexigétantquela structure générale dela distribution estpréservée.En plus dela notation//de Kpathsea, le chemin derechercherécursive peutégalement débuterpar〈DEVICE〉:/^,parexemple:TeXMF:/^,quiexaminera ce périphérique spécifique defaçon complète. Les binairesfournis avecla distributionAmiWeb2c sont installés danslerépertoirebin/amiweb2c/en dehors del’arborescenceTDS communeshare/texmf/^.En plus de cetensemble de binairesAmiWeb2c,on trouvera deux sous-répertoires local/ ^et pastex/ ^avec les programmes auxi- liaires.Uneversion allégée du système PasTEXest fournie avecAmiWeb2c(avec l’aimable autorisation deGeorg Heßmann),pré-installée dans son proprerépertoire share/texmf/amiweb2c/pastex/^{.Si vous}voulez utiliserPasTEX, vous devez as- signer le nomTeX:^{à cet}emplacement.Desfichiers de documentation auformat AmigaGuide devraient être stockés endoc/guide/, similaire àdoc/info/. B.3.2 Public DECUS TEX

Siune autreimplantationVMS,en plus dela PublicDECUSTEX,existe, le nom de répertoire de premierniveau del’implantation sera modifié en quelque chose de plus spécifique (par exemple :vms_decus).

texmf/

vms/ fichiers spécifiques à l’implantation VMS exe/ commandes utilisateur finales

common/ procédures, fichiers de définitions de commandes, etc.

axp/ binaires exécutables pour Alpha AXP vax/ binaires exécutables pour VAX formats/ fichiers de pool, formats, bases

help/ bibliothèque d’aide VMS et sources d’aides divers

mgr/ programmes, docs, . . . , pour la gestion du système B.3.3 Web2c 7

Tousles fichiers dépendants del’implantationTEX (.pool^,.fmt^,.base^,.mem⁾ sontstockés pardéfautdirectementdanstexmf/web2c^{. Lefichier}de configura- tiontexmf.cnfet les scriptsMakeTeX...utilisés comme sous-programmes sont égalementstockés à cetendroit. Lesfichiers spécifiques nonTEXsontstockés en suivant le codage standard deGNU.Àpartird’unrépertoireracine〈préfixe〉,nous avons les emplacements par défaut suivant :

〈préfixe〉/ racine de l’installation (/usr/localpar défaut)

bin/ exécutables

man/ pages de man

info/ fichiers info

lib/ bibliothèques (libkpathsea.*) share/ fichiers dépendants de l’architecture

texmf/ racine TDS

web2c/ fichiers dépendants de l’implantation (.fmt,texmf.cnf, etc.) Voirhttp://www.gnu.org/prep/standards_toc.html^{pour les} raisons et les descriptions de cetarrangement.Un site peutévidemmentne pastenircompte de ces emplacements pardéfaut,parexemple en plaçant toutsous un seul réper- toire tel que/usr/local/texmf.

C Y a-t-il une meilleure solution ?

La définition delaTDS a nécessité de nombreuxcompromis. La structure géné- rale ainsiqueles détailsrelatifs à chaquerépertoire ontété arrêtés entrouvant unterrain d’entente entre de nombreuses opinions. Lesidées directrices étaient la faisabilité(entermes de ce quipouvait techniquementêtreréalisé etce quel’on pouvait raisonnablementattendre des développeurs)et larégularité(lesfichiers devantêtreregroupés selon une disposition qui «avaitun sens»).Certainesidées intéressantes n’ontpas pu être appliquées à cause du manque de supportnécessaire des implantations :

– Contrôle du chemin derecherche au niveau deTEX.Si les documents pouvaient restreindre la recherche de sous-répertoires à un certain sous-répertoire par l’in- termédiaire d’une certaine syntaxe portable au niveau des noms defichiers, les restrictions sur l’unicité des noms de fichiers auraient pu être considérablement relâchées(avecla participation desformats)et les chemins derecherche deTEX n’auraient pas eut besoin de dépendre du format.

– Plusieurs arborescenceslogiquestexmf^.Parexemple,un site auraitpu avoirun emplacement (enlecture seule)pour lesfichiers stables etdifférents emplace- ments(accessibles en écriture)pour lesfontes créées defaçon dynamique et d’autresfichiers. Ilauraitétéraisonnable pourdeux tels arbres d’êtrelogiquement assemblés lors des recherches. On se référera à l’article de Michael Downes dans les références pour voir comme cela peut fonctionner en pratique avec Web2C.

C.1 Structure pour les macros

LeTWGs’estmis d’accord sur la disposition〈format〉/〈package〉après delongues discussions sur la meilleure façon de placer les fichiers. L’autre choix princi- pal à cette disposition était le schéma qui inversait l’ordre de cesrépertoires :

〈package〉/〈format〉.Cerenversementavaitun grandintérêt : il laissait tousles fichiersrelatifs à un package particulierau niveau d’un emplacementunique. L’ar- rangement effectivement adopté tend à disperser les fichiers au niveau de deux ou trois emplacements(macros,documentations et fontes,parexemple,sontdispersés dans différentes directions del’arbre dèsle premierniveau).Cependant, la structure

〈format〉/〈package〉a gagné pour deux raisons :

– C’estplus proche dela pratique courante.Enréalité,plusieurs membres duTWG avait déjà implanté la hiérarchie TDS. La seconde solution n’avait été utilisée sur aucun des sites connus et leTWGavait le sentimentqu’imposerquelque chose qui n’avait aucune expérience pratique serait une erreur.

– La secondefaçon defaire augmentele nombre derépertoires de premierniveau etainsi, lesfichiers auraitdû êtretrouvés avec unerecherche de sous-répertoires devanteffectuersa propagation dans un arbrelarge etpeu profond.Cela aurait pu avoirun profondimpactau niveau del’efficacité delarecherche de sous- répertoires.

C.2 Structure des fontes

LeTWGs’estplus disputé à propos desfontes que pourn’importe quelautre sujet.

Ce n’estpas surprenant : la nécessité d’utiliser lesfontes PostScript,en pleine proli- fération,avecTEXarendul’arrangementprécédentavectous sesfichiers dans un seul répertoire intenable et, par conséquent, a initié l’effort de la TDS.

C.2.1 Emplacement par type de fichier de fontes

Nous avons considérél’arrangementaveclefournisseuren premier,arrangement utilisé sur de nombreux sites :

texmf/fonts/〈fournisseur〉/〈famille〉/〈type〉/

Celafacilitela maintenance del’arborescence desfontes puisquetouslesfichiers appartenantà unefamille donnée étaientau même emplacement.Mais,à moins quetousles programmes effectuantdesrecherches dans cetarbre n’emploientune certaineforme de cache, il risque d’yavoirde sérieuxproblèmes de performance.Par exemple,afin detrouverunfichierTFM, la plus simple desimplantations demandera àTEXderechercheràtraverstousles sous-répertoires quicontiennent lesfichiers PK danstousles modes etàtouteslesrésolutions.Finalement,un sondage auprès de développeurs arévélé unerésistance considérable àl’implantation de suffisamment de mécanismes de cache.Ce schéma a donc été abandonné. Le schéma delaTDS permetau moins àlarecherche arborescente de selimiterà untype correctde fichier.Desréserves à propos del’efficacité demeurentmaisilsemble qu’on ne puisse pas mieux faire sans abandonnerentièrement larechercherécursive.Nous avons égalementpensé àregrouper touslesfichiers defontes par type defichierafin queles sourcesMETAFONT^{soientdans unrépertoire}texmf/fonts/mf^{, lesfichiers} deliste de propriétés danstexmf/fonts/pl^{, les}formes diverses desfontesType1 séparées,etainside suite.Bien qu’évidemmentplus consistante,nous avons pensé quelerevers dela médaille consistanten une plus grande complication au niveau dela constructions des chemins étaitplusimportant. LaTDSrassemble quelques types defichiers(mf^etpl^soussource^,pfa^,pfb^etgsf^soustype1) là où nous pensons que c’est avantageux.

C.2.2 Emplacement du mode et de la résolution

Nous avons considéré placer lemodeau plus profond del’arborescence desfontes: texmf/fonts/pk/〈fournisseur〉/〈famille〉/〈mode〉/〈dpi〉/

Dans ce cas,cependant, ilestdifficile delimiter larecherche de sous-répertoires au mode nécessaire à un périphérique particulier.Nous avons alors pensé à déplacer ledpi〈nnn〉au dessous du mode :

texmf/fonts/pk/〈mode〉/〈dpi〉/〈fournisseur〉/〈famille〉/

Mais alorsiln’estplus possible d’omettrele niveaudpi〈nnn〉pour les systèmes qui peuvent choisir d’utiliser les noms de fichiers longs.

C.2.3 Fontes bitmap sans mode

LaTDS demande d’utiliserunrépertoire uniquemodeless/^commele nom de mode pour les utilitaires quiproduisentdesfontes bitmap,parexempletexmf/fonts/

modeless/times/^{.Cela a}le considérable avantage de ne pas exigerque chaque nom derépertoire de cetype soit listé dansle chemin derecherche.Une autre pos- sibilité étaitd’utiliser le nom del’utilitaire au-dessous duquel touslesrépertoires