> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/fr/articles-approfondis/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md). # Introduction à Kpathsea et à la façon dont les moteurs TeX recherchent les fichiers ## Introduction Cet article présente une introduction à la manière dont les moteurs TeX localisent les fichiers nécessaires pour composer votre document — en utilisant LaTeX ou tout autre ensemble de macros. Bien qu’Overleaf dispense les utilisateurs des difficultés liées à la gestion d’une installation TeX ([TeX Live](https://www.tug.org/texlive/)), les bases de la manière dont les moteurs TeX recherchent des fichiers seront utiles/intéressantes si vous souhaitez créer une structure de dossiers pour vous aider à gérer votre projet Overleaf. Pourquoi cela serait-il vrai ? Si vous stockez certains fichiers de votre projet Overleaf dans des dossiers, LaTeX pourrait ne pas trouver ces fichiers parce que, par défaut, le moteur TeX (compilateur) pourrait ne pas *savoir* qu’il doit rechercher dans ces dossiers — il ne trouvera donc pas les fichiers qu’ils contiennent. Pour éviter cela, vous pouvez créer et ajouter à votre projet un fichier de configuration appelé un [fichier latexmkrc](https://mg.readthedocs.io/latexmk.html#configuration-files) qui peut être utilisé pour indiquer à un moteur TeX que vos dossiers existent et qu’il doit les rechercher. Si vous voulez voir un exemple montrant un fichier latexmkrc, vous pouvez lire cet article d’aide : [Comment utiliser latexmkrc avec Overleaf : exemples et techniques](/latex/fr/articles-approfondis/28-how-to-use-latexmkrc-with-overleaf.md). Il n’est peut-être pas immédiatement évident de comprendre comment, ou pourquoi, ce fichier latexmkrc fonctionne réellement. Si vous souhaitez savoir pourquoi et, peut-être, mieux comprendre pour l’utiliser avec d’autres possibilités de configuration pour votre projet, poursuivez votre lecture... À la fin de cet article, nous travaillerons sur un [exemple pratique](#kpathsea-and-texinputs-latexmkrc-file-to-the-rescue)— en utilisant notre connaissance de la façon dont TeX recherche les fichiers—pour créer un fichier latexmkrc permettant de gérer des dossiers imbriqués contenant vos fichiers graphiques. ## TeX et indépendance vis-à-vis de la plateforme Lorsque Knuth a créé TeX, l’indépendance vis-à-vis de la plateforme était un principe central guidant sa conception et son implémentation, et cette philosophie se retrouve dans le fonctionnement interne de TeX (par exemple, l’utilisation de l’arithmétique entière, de la gestion « maison » des chaînes de caractères, de la gestion mémoire, etc.). Aujourd’hui encore, l’indépendance vis-à-vis de la plateforme des moteurs modernes basés sur TeX soulève des questions et des débats sur les forums publics ; par exemple, voir cette discussion sur tex.stackexchange : [XeTeX et LuaTeX sont-ils dépendants de la plateforme ?](https://tex.stackexchange.com/questions/94297/are-xetex-and-luatex-platform-dependent) qui contient des commentaires et des observations formulés par un certain nombre d’experts TeX réputés. Cependant, pour l’instant, laissons de côté les détails et notons que les moteurs TeX doivent tout de même être hautement portables — capables de fonctionner sur plusieurs systèmes d’exploitation et de produire des résultats « identiques ». Un aspect clé de la portabilité est la recherche de fichiers d’une manière indépendante de la plateforme. ## Les moteurs TeX ne recherchent pas les fichiers… vraiment !? Non, les moteurs TeX ne *directement* recherchent pas les fichiers *eux-mêmes*. Lors du traitement d’un `.tex` fichier, un moteur TeX peut identifier le besoin d’ouvrir un fichier particulier, mais il *délègue* la tâche de le trouver à un autre logiciel appelé [*Kpathsea*](https://tug.org/kpathsea/): une bibliothèque logicielle externe qui ne fait pas partie du code source « cœur » des moteurs TeX. Ce que Kpathsea fournit est, en pratique, une *cœur* interface de programmation d’application ([Application Programming Interface](https://en.wikipedia.org/wiki/Application_programming_interface)) que les moteurs TeX (ainsi que BibTeX, MetaPost et d’autres applications) peuvent appeler chaque fois qu’ils ont besoin d’ouvrir un fichier particulier : Kpathsea effectue le travail réel de localisation de ce fichier. Lorsque Knuth a écrit le moteur TeX d’origine — dont tous les autres moteurs TeX descendent, en définitive —, le problème de trouver/ouvrir des fichiers constituait un défi important, en partie à cause de l’écosystème technologique très disparate de cette époque. En fait, dans le code source de TeX, Knuth qualifie l’entrée/sortie des fichiers de « fléau de la portabilité » (voir page 12, section 25 de [TeX : The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)). La communauté TeX a reconnu la nécessité d’harmoniser (standardiser) la recherche de fichiers pour TeX —*et les logiciels liés à TeX*— et a décidé de doter TeX des outils nécessaires pour cela. Pour résoudre le problème très épineux d’une méthode indépendante de la plateforme pour trouver des fichiers, Karl Berry, membre éminent de la communauté TeX, a écrit le logiciel destiné à résoudre le problème de *recherche de*-recherche de chemins : une solution qu’il a nommée [**Kpathsea**](http://tug.org/texinfohtml/kpathsea.html)— qui est dérivé de **K**arl’s **Path** **Sea**rching (voir cet [entretien avec Karl Berry](http://www.tug.org/interviews/berry.html)). On peut noter qu’il s’appelle K**recherche de**sea et non K**modifiable**sea parce que, comme le [documentation](http://tug.org/texinfohtml/kpathsea.html) le note, c’est une bibliothèque de recherche de \*chemins\*. Il est important de reconnaître que Kpathsea n’est pas utilisé uniquement par les moteurs TeX ; divers programmes liés à TeX, notamment BibTeX et MetaPost, utilisent également Kpathsea pour rechercher des fichiers d’entrée. En résumé, chaque fois que les macros TeX/LaTeX doivent ouvrir un fichier particulier, les commandes à partir desquelles ces macros sont construites seront, en fin de compte, converties en instructions TeX de bas niveau (les primitives TeX) que les moteurs TeX exécutent réellement. Si ces instructions incluent la nécessité d’ouvrir un fichier, le moteur TeX fera appel à Kpathsea en disant, en substance, « veuillez trouver ce fichier » ; si cette recherche Kpathsea réussit, le fichier est ouvert. Cependant, si Kpathsea ne parvient pas à localiser le fichier, le moteur TeX en sera informé et arrêtera l’exécution pour afficher la célèbre erreur ``! Je ne peux pas trouver le fichier `...'`` En réalité, Kpathsea ne peut pas le trouver. ### Notes sur LuaTeX À proprement parler, nous devrions nuancer cette section en notant que LuaTeX offre un mécanisme permettant à l’utilisateur de fournir son propre code de recherche de fichiers par l’utilisation de *fonctions de rappel*. LuaTeX permet aux utilisateurs d’écrire des fonctions dans le langage de script Lua et de les enregistrer auprès de LuaTeX afin qu’il appelle cette fonction définie par l’utilisateur à certaines étapes de l’exécution de LuaTeX — d’où le terme *fonctions de rappel*de rappel [Le manuel de référence LuaTeX](http://www.pragma-ade.com/general/manuals/luatex.pdf) C’est une technique très puissante et le lecteur intéressé peut trouver davantage d’informations dans la section 9 de ### (au moment de la rédaction, ce lien renvoie vers LuaTeX 1.09). Le fichier de configuration Kpathsea : texmf.cnf `Chaque installation TeX contient un fichier texte appelé` texmf.cnf *qui est un fichier de configuration utilisé par Kpathsea : il contient de nombreuses « variables de configuration » qui définissent les chemins que Kpathsea utilisera pour rechercher divers types de fichiers dont les moteurs TeX (ou BibTeX, MetaPost, etc.) pourraient avoir besoin. Comme nous le verrons ci-dessous, ces « variables de configuration » définissent des chemins de recherche construits à partir de ce qu’on appelle des*: en utilisant divers éléments de construction, variables et paramètres pour définir chaque élément de chemin comme un « modèle » que Kpathsea traite afin de générer les répertoires physiques réels à rechercher. Pour donner un exemple concret, voici une telle variable de configuration qui définit les chemins de recherche pour les polices OpenType — pour l’instant, ne vous inquiétez pas du sens de la construction de ce chemin : ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` Tout ce qui importe ici, c’est que le fichier `Chaque installation TeX contient un fichier texte appelé` (lu par Kpathsea) définit une variable de configuration appelée `OPENTYPEFONTS` qui sert à définir le ou les chemins que Kpathsea utilisera pour rechercher les polices OpenType. Le côté droit du « = » ne ressemble pas à un chemin que l’on voit sur un appareil classique parce qu’il est construit à l’aide de diverses variables et de paramètres pour définir chaque chemin comme un « modèle » ou un « plan » que Kpathsea utilisera pour générer les répertoires réels à rechercher. ### La notion de « chemin » chez Kpathsea Le concept central à comprendre est peut-être la notion de « chemin » chez Kpathsea : la structure de base que Kpathsea utilise pour déterminer où se trouve un fichier particulier. Comme nous l’avons vu dans l’ `OPENTYPEFONTS` exemple ci-dessus, la notion de chemin de Kpathsea est très différente des chemins que nous avons l’habitude d’utiliser sur nos appareils de bureau ou portables. Pour citer la [documentation](http://tug.org/texinfohtml/kpathsea.html#Searching-overview): > ... un *chemin de recherche* est une liste d’ *éléments de chemin*, qui sont des noms de répertoires avec quelques « fioritures » supplémentaires. — mais notez qu’un point-virgule (`;`) est également utilisé pour séparer *éléments de chemin*. Plus loin, nous indiquerons brièvement la nature de certaines de ces « fioritures » supplémentaires. Dans notre `OPENTYPEFONTS` exemple, il y a trois éléments de chemin, chacun délimité à l’aide d’un point-virgule (`;`): ![Image montrant les éléments de chemin contenus dans une définition de chemin Kpathsea](/files/3c9ce8ea3964995725a4f2f92ab4fe3c17c23ff9) 1. `.` (c’est-à-dire le répertoire courant) 2. `$TEXMF/fonts/{opentype,truetype}//` 3. `$OSFONTDIR//` Notez qu’un double slash (`//`) dans un élément de chemin signifie rechercher les sous-répertoires (de manière récursive). Un `Chaque installation TeX contient un fichier texte appelé` fichier contiendra de nombreuses « variables de configuration » pour définir les chemins de recherche des types de fichiers que Kpathsea peut rechercher. ## Kpathsea : aperçu très bref Kpathsea est une bibliothèque sophistiquée — avec de nombreux détails et nuances — et même un bref coup d’œil à sa [documentation](http://tug.org/texinfohtml/kpathsea.html) montre clairement que nous ne pouvons pas entrer dans tous les détails. Cependant, nous pouvons essayer d’en donner un aperçu — pour aider à orienter votre réflexion et offrir un point de départ pour une lecture plus approfondie. ### But de base de Kpathsea Comme indiqué dans la documentation, le but fondamental de Kpathsea est « de renvoyer un nom de fichier à partir d’une liste de répertoires spécifiés par l’utilisateur » et ces répertoires (chemins de recherche) sont spécifiés à l’aide de « quelques fioritures supplémentaires ». ### Ces « fioritures supplémentaires » Les « quelques fioritures supplémentaires » mentionnées ci-dessus comprennent divers paramètres et variables que Kpathsea utilise pour construire ses chemins de recherche (ou « modèles de chemin »), afin qu’il puisse définir les chemins de manière plus générale. Lorsqu’un moteur TeX est réellement en cours d’exécution, Kpathsea peut utiliser la valeur actuelle de ces paramètres/variables pour déterminer les chemins réels en remplaçant ces variables par leurs valeurs réelles (au moment de l’exécution). Vous pouvez facilement identifier ces variables (au sein des éléments de chemin) car elles commencent par un `$` signe. Ainsi, nous disons que Kpathsea *développe* un élément de chemin, ce qui signifie qu’il transforme ces paramètres et variables : en faisant passer un « modèle » de chemin au(x) nom(s) réel(s) d’un ou plusieurs répertoires physiques dans lesquels rechercher un fichier. Cela offre une grande flexibilité et signifie que Kpathsea peut construire une liste de répertoires correspondant à un élément de chemin individuel — par exemple, s’il lui est demandé de rechercher des sous-répertoires. ### Retour sur notre exemple OpenType Nous allons rassembler les différents fils et explorer `OPENTYPEFONTS` un peu plus en détail : ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` Considérons les deux éléments de chemin `$TEXMF/fonts/{opentype,truetype}//` et `$OSFONTDIR//`. Ici, Kpathsea remarque l’utilisation des accolades `{...}` et considère `$TEXMF/fonts/{opentype,truetype}` comme représentant *deux* éléments de chemin : 1. `$TEXMF/fonts/opentype//` 2. `$TEXMF/fonts/truetype//` et que les *sous-répertoires* de ces deux éléments de chemin doivent également être recherchés (indiqué par le suffixe `//`). **Remarque**: voir la documentation de Kpathsea sur [l’expansion des sous-répertoires](http://tug.org/texinfohtml/kpathsea.html#Subdirectory-expansion) pour une mise en garde importante sur l’ordre dans lequel les sous-répertoires, à n’importe quel niveau, sont recherchés (cet ordre n’est pas spécifié). Nous ferons quelques observations sur `$TEXMF` ci-dessous. #### $OSFONTDIR// `$OSFONTDIR` est une variable dont la valeur doit être définie comme une variable d’environnement contenant l’emplacement où les polices sont stockées : la valeur exacte dépendra bien sûr du système d’exploitation utilisé pour exécuter TeX. Notez qu’ici, le suffixe `//` indique à Kpathsea de rechercher les sous-répertoires lors de la recherche des polices OpenType. La définition par défaut de `OSFONTDIR` dans `Chaque installation TeX contient un fichier texte appelé` est : ``` OSFONTDIR = /please/set/osfontdir/in/the/environment ``` Il s’agit donc certainement d’une valeur que vous devez définir si vous souhaitez l’utiliser — votre variable d’environnement remplacera cette définition « factice » contenue dans `Chaque installation TeX contient un fichier texte appelé`. Si vous définissez la variable d’environnement `OSFONTDIR` alors, à l’exécution, partout où Kpathsea voit `$OSFONTDIR` dans un élément de chemin (dans `Chaque installation TeX contient un fichier texte appelé`) il peut remplacer la variable `$OSFONTDIR` par la valeur réelle stockée dans la variable d’environnement `OSFONTDIR`. Rappelez-vous que, lorsque vous l’utilisez dans des `Chaque installation TeX contient un fichier texte appelé` éléments de chemin, nous indiquons la variable `$OSFONTDIR`— avec un signe `$`— pour indiquer à Kpathsea qu’il s’agit d’une variable dont la *valeur* doit être utilisée. #### Brèves notes sur $TEXMF `TEXMF` est une autre variable de configuration définie dans `Chaque installation TeX contient un fichier texte appelé`; par exemple, dans la distribution principale de TeX Live, vous verriez : ``` TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDIST} ``` Vous n’avez pas besoin de vous préoccuper des détails de cette définition de `TEXMF`— nous n’explorerons pas tous les détails, mais notons simplement que la `$TEXMF` variable est utilisée dans les éléments de chemin parce qu’elle définit une série de dossiers de premier niveau (appelés « arbres texmf ») à partir desquels vous pouvez commencer la recherche de fichiers. `TEXMF` est extrêmement utile si vous souhaitez, ou devez, répartir une installation TeX sur plusieurs répertoires (ou « arbres » de répertoires). Par exemple, avoir une collection principale ou maîtresse de paquets TeX/LaTeX (par exemple, TeX Live) et une autre collection de fichiers et dossiers utilisés pour stocker des paquets LaTeX locaux — ou, peut-être, pour stocker des fichiers de configuration locaux ou des versions personnalisées de paquets standard. Répartir l’installation TeX de cette manière peut faciliter la gestion des mises à niveau de la collection principale/maîtresse (distribution) de paquets TeX/LaTeX, car votre collection locale est séparée des fichiers maîtres qui sont mis à jour lorsque vous mettez à niveau votre distribution/installation TeX Live. Pour plus de détails sur la gestion d’installations TeX plus complexes, le lecteur intéressé est renvoyé à ces deux articles : * [Gérer plusieurs arbres TDS](http://tug.org/TUGboat/Articles/tb22-3/tb72downes.pdf) par Michael J Downes ; * [Jongler avec les arbres texmf](http://www.ntg.nl/maps/27/17.pdf) par Siep Kroonenberg. #### Structure de répertoires TeX Toute personne ayant géré une installation TeX sait que les systèmes TeX modernes, tels que TeX Live, contiennent des dizaines de milliers de fichiers couvrant un vaste éventail de types de fichiers. La TeX Directory Structure (TDS) a été conçue comme un « plan » de bonnes pratiques pour organiser la vaste collection de fichiers d’une installation TeX fonctionnelle et est fortement recommandée pour une utilisation avec Kpathsea. Pour plus d’informations, le lecteur est dirigé vers la spécification TDS : [Une structure de répertoires pour les fichiers TeX](https://www.tug.org/tds/tds.pdf). ## Types de fichiers Kpathsea La suite d’applications qui utilisent Kpathsea doit accéder à une large gamme de types de fichiers, donc Kpathsea utilise une « variable de configuration » pour identifier le ou les chemins correspondant à chaque type de fichier (ou groupe de fichiers) qu’il prend en charge. La documentation en ligne donne une liste complète (voir aussi notre [tableau récapitulatif ci-dessous](#table-listing-kpathsea-config-variables)) mais voici les « variables de configuration » pour les types de fichiers les plus courants : | | | | ----------------------------- | ------------------------------------------------------ | | **Variable de configuration** | **Exemples de types de fichiers** | | TEXINPUTS | Fichiers sources TeX et fichiers de figures/graphismes | | BIBINPUTS, BSTINPUTS | Fichiers sources de bibliographie BibTeX | | TTFONTS | Polices vectorielles TrueType | | OPENTYPEFONTS | Polices vectorielles OpenType | `TEXINPUTS` est une variable de configuration particulièrement importante parce qu’elle précise où un moteur TeX obtient ses fichiers sources d’entrée. Notez que les fichiers image sont considérés comme des fichiers d’entrée et peuvent également être recherchés à l’aide du chemin défini par `TEXINPUTS`. ### Quelques nuances de Kpathsea Comme indiqué, Kpathsea présente de nombreuses nuances que nous ne pouvons pas explorer ici en détail. Cependant, voici des fonctionnalités que certains lecteurs voudront peut-être explorer : * **base de données des noms de fichiers :** Pour minimiser les recherches sur disque, Kpathsea peut utiliser une « [fichier de base de données des noms de fichiers appelé ls-R](http://tug.org/texinfohtml/kpathsea.html#Filename-database) qui associe les fichiers aux répertoires ». TeX Live en fournit un, ainsi que les outils pour le mettre à jour si de nouveaux fichiers sont ajoutés. * **variables d’environnement**: en plus des « variables de configuration » (telles que `OPENTYPEFONTS`) Kpathsea fait aussi un usage astucieux des [variables d’environnement](https://en.wikipedia.org/wiki/Environment_variable); par exemple, la valeur à l’exécution des variables d’environnement peut être utilisée pour définir des éléments de chemin dans le `Chaque installation TeX contient un fichier texte appelé` fichier (éventuellement pour remplacer des variables du même nom définies dans `Chaque installation TeX contient un fichier texte appelé`). * **nom du programme :** Un aspect subtil mais essentiel du comportement de Kpathsea est qu’il peut utiliser le nom du programme exécutable (par exemple, le moteur TeX) pour construire des structures de chemins de recherche spécifiques au programme. Cela offre une flexibilité considérable car la recherche de chemins peut être dirigée vers des fichiers pour un moteur TeX particulier. Par exemple, pour LuaTeX/LuaLaTeX : ``` TEXINPUTS.lualatex = .;$TEXMF/tex/{lualatex,latex,luatex,generic,}// TEXINPUTS.luatex = .;$TEXMF/tex/{luatex,plain,generic,}// ``` * **localisation `Chaque installation TeX contient un fichier texte appelé`**: Une question que vous vous posez peut-être est la suivante : comment Kpathsea sait-il où `Chaque installation TeX contient un fichier texte appelé` est stocké ? La réponse est une variable d’environnement appelée `TEXMFCNF`. Celle-ci doit être définie (sur l’appareil/la plateforme exécutant TeX) sur le chemin où `Chaque installation TeX contient un fichier texte appelé` est stocké. #### Débogage des problèmes Kpathsea Les utilisateurs d’Overleaf auront peu de chances d’avoir besoin de ces fonctionnalités, mais nous les listons par souci d’exhaustivité : * **kpsewhich**: un programme autonome (inclus dans TeX Live) qui peut être utilisé pour tester vos paramètres : déterminer la valeur des variables et trouver des fichiers. Les lecteurs intéressés sont renvoyés à la [documentation en ligne](http://tug.org/texinfohtml/kpathsea.html#Invoking-kpsewhich) pour plus d’informations. * **variables d’environnement**: Kpathsea prend en charge une variable d’environnement appelée [`KPATHSEA_DEBUG`](http://www.tug.org/texinfohtml/kpathsea.html#Debugging) pour aider à déboguer son comportement. Vous pouvez définir `KPATHSEA_DEBUG` sur différentes valeurs selon la quantité d’informations de débogage dont vous avez besoin. Définir `KPATHSEA_DEBUG=-1` générera une *importante* de données. ## Et enfin : dossiers, fichiers de figures et latexmkrc Alors, comment ce qui précède se rapporte-t-il à latexmkrc ? Si vous lisez cet article [Comment utiliser latexmkrc avec Overleaf : exemples et techniques](/latex/fr/articles-approfondis/28-how-to-use-latexmkrc-with-overleaf.md) vous pouvez voir que le code (Perl) de l’exemple latexmkrc définit la valeur d’une variable d’environnement `TEXINPUTS`: ``` $ENV{'TEXINPUTS'}='./tex//:' . $ENV{'TEXINPUTS'}; ``` Notez que le deux-points (:) utilisé ici (`./tex//**:**`) est *extrêmement* est important. Si vous omettez ce deux-points, TeX/LaTeX risque de ne pas pouvoir trouver des fichiers système essentiels, tels que les paquets LaTeX ! Ce que fait, en pratique, ce fichier latexmkrc, c’est ajouter un chemin de dossier de premier niveau (`./tex` dans l’exemple ci-dessus) à la variable d’environnement définie par le système `TEXINPUTS` afin que, lorsque Kpathsea utilise la variable `$TEXINPUTS` il sache alors que le dossier `/tex//` doit être recherché pour trouver les fichiers d’entrée. Si vous regardez attentivement, vous verrez que le chemin réellement utilisé est `./tex//:` le `//` indique à Kpathsea de rechercher récursivement le dossier tex — c’est-à-dire de regarder dans tous les sous-dossiers contenus dans le `tex` dossier. Comme indiqué, nous avons également ajouté le caractère deux-points important. Nous pouvons utiliser exactement la même technique pour les fichiers de figures. ### En aparté sur BibTeX Comme indiqué, le programme BibTeX utilise également Kpathsea pour rechercher ses fichiers d’entrée ; en particulier : * le `BSTINPUTS` variable de configuration (chemin de recherche) est utilisée pour rechercher `.bst` fichiers ; * et le `BIBINPUTS` variable de configuration (chemin de recherche) sera utilisée pour rechercher `.bib` autonomes. Si vous ajoutez de nouveaux `.bst` ou `.bib` fichiers à votre projet Overleaf, vous pouvez utiliser la technique ci-dessous pour indiquer à BibTeX où trouver ces fichiers — vous devez remplacer `TEXINPUTS` avec `BSTINPUTS` et/ou `BIBINPUTS`. ### TEXINPUTS et utilisation de dossiers imbriqués pour les fichiers graphiques Si votre projet contient beaucoup de fichiers graphiques, il peut être pratique de créer un ensemble de dossiers pour les stocker et les gérer. Par exemple, la capture d’écran suivante montre une section d’un projet Overleaf qui utilise un dossier de premier niveau appelé **`graphics`**: ![Image montrant des dossiers imbriqués dans un projet Overleaf](/files/84f87dee15a21ff67be74fffc686af92c184c399) Il existe de nombreux sous-dossiers (imbriqués) contenant des graphiques pour diverses sections de notre document. Supposons que nous ayons la structure de dossiers ci-dessus et que nous voulions utiliser le `graphicx` package (`\usepackage{graphicx}`) et que nous essayions de le faire ainsi : ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% la bonne pratique consiste à ne pas utiliser l’extension du fichier \end{document} ``` Cela ne fonctionnera pas et vous obtiendrez une erreur comme celle-ci : ``` ! Erreur LaTeX : fichier `endlinechar' introuvable. l.4 \includegraphics{endlinechar} Je n’ai pas pu localiser le fichier avec aucune de ces extensions : .pdf,.PDF,.ai,.AI,.png,.PNG,.jpg,.JPG,.jpeg,.JPEG,.jp2,.JP2,.jpf,.JPF,.bmp,.BMP, ,.ps,.PS,.eps,.EPS,.mps,.MPS,.pz,.eps.Z,.ps.Z,.ps.gz,.eps.gz ``` Cette erreur se produit parce que notre fichier graphique est stocké dans un emplacement que TeX/LaTeX (et Kpathsea) ignorent, et ne peuvent donc pas le trouver — le chemin vers le fichier graphique est : ``` ./graphics/Introduction/Chapter1/Section1/Subsection3/endlinechar.png ``` **Remarque**: Il est généralement admis comme bonne pratique d’ ***éviter les espaces dans les noms de dossiers***. Bien qu’il soit certainement possible d’avoir des espaces dans les noms de dossiers, en utilisant les techniques abordées ci-dessous, nous vous mettons en garde contre cette pratique pour des raisons de portabilité du document en dehors de la plateforme Overleaf. Comme expliqué dans cet [article d’aide Overleaf](/latex/fr/autres-sujets/27-inserting-images.md) vous pouvez, bien sûr, utiliser des dossiers pour stocker vos graphiques, mais vous devez indiquer à LaTeX où ils sont stockés. Ici, nous examinerons deux solutions : * Utiliser la commande \graphicspath ; * Utiliser notre connaissance de Kpathsea et `TEXINPUTS`. ### Utiliser \graphicspath Le `graphicx` package fournit la `\graphicspath` commande que vous pouvez utiliser pour déclarer les chemins où se trouvent vos graphiques ; nous pourrions donc faire quelque chose comme ceci : ```latex \graphicspath{{./graphics/Introduction/Chapter1/Section1/Subsection3/}} ``` et LaTeX trouvera désormais tout graphique stocké sous ce chemin. **Remarque**: Si vous *devez* avez des espaces dans les noms de dossiers, alors vous devrez encadrer les chemins par des guillemets doubles (`"..."`): ```latex \graphicspath{{"./graphics/Introduction/Chapter 1/Section 1/Subsection 3/"}} ``` **Remarque**: Vous pouvez déclarer plusieurs chemins comme ceci : ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` où `...` signifie des chemins supplémentaires encadrés par des accolades. **Remarque**: Nous commençons le chemin avec `./graphics` et non pas seulement `/graphics`. Le point (.) indique au système d’exploitation que le chemin est relatif au répertoire de travail courant. Le `\graphicspath` commande fonctionne bien, mais si vous avez de nombreux dossiers, il peut devenir assez fastidieux d’ajouter chaque chemin ; de plus, les chemins définis via `\graphicspath` ne fonctionneraient plus si vous renommiez les dossiers ou les réorganisiez. Existe-t-il un moyen plus simple ? Oui, vous pouvez utiliser un fichier latexmkrc ! #### \graphicspath et récursion (sous-répertoires) Notez qu’il existe des discussions/débats en ligne sur la question de savoir si certains systèmes prennent en charge/permettent `\graphicspath` de rechercher récursivement les sous-répertoires si vous ajoutez `//` à la fin du chemin : voir, par exemple, ces discussions sur tex.stackexchange : * [Recherche récursive de \graphicspath en LaTeX](https://tex.stackexchange.com/questions/25443/latex-graphicspath-recursive-search); * [Graphicspath pour MikTeX](https://tex.stackexchange.com/questions/3131/graphicspath-for-miktex). Pour une compatibilité maximale, vous devriez supposer que `\graphicspath` ne prend pas en charge la recherche récursive dans les répertoires. ### Kpathsea et TEXINPUTS (fichier latexmkrc à la rescousse) **AVERTISSEMENT :** Notez que la technique suivante fonctionne bien sur Overleaf et sur des installations TeX locales correctement configurées ; **mais** si vous utilisez un fichier latexmkrc, votre projet peut devenir incompatible avec d’autres installations TeX, telles que celles utilisées par les éditeurs et les systèmes de soumission de revues en ligne. Les installations TeX tierces peuvent, ou non, prendre en charge ou autoriser l’utilisation de latexmkrc. Si vous devez exporter votre projet Overleaf pour l’utiliser ailleurs, ou si vous souhaitez le soumettre à une revue, vous devriez supprimer tout espace dans les noms de chemin et, pour une meilleure compatibilité, ajouter une `\graphicspath` commande qui définit tous les chemins : ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` où `...` signifie des chemins supplémentaires encadrés par des accolades. La technique abordée ci-dessous (utilisant `TEXINPUTS`) a été testée avec succès sur Overleaf avec les moteurs pdfTeX, XeTeX et LuaTeX (c’est-à-dire les options de compilation pdfLaTeX, XeLaTeX et LuaLaTeX dans le menu Overleaf) : ![Image montrant comment choisir le compilateur LaTeX sur Overleaf](/files/17653a682a93a20893fc6859100e743bd8d1a477) Pour revenir à notre exemple, nous voulons utiliser ce code (avec des dossiers profondément imbriqués) et nous utiliserons un fichier latexmkrc pour y parvenir : ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% la bonne pratique consiste à ne pas utiliser l’extension du fichier \end{document} ``` Voici une capture d’écran montrant le code ci-dessus fonctionnant sans problème : LaTeX a trouvé notre fichier graphique (`endlinechar.png`) bien qu’il se trouve dans une structure de dossiers profondément imbriquée (sans aucun espace dans les noms de dossiers). ![Image montrant un projet avec des dossiers imbriqués en cours de compilation sur Overleaf](/files/40adce7f5aaf091a9782bd3046855a0c140f6ad1) Alors, comment avons-nous fait cela ? Il vous suffit de : * créez un nouveau fichier, sans extension, et appelez-le latexmkrc ; * ajoutez la ligne suivante à ce fichier : ``` $ENV{'TEXINPUTS'}='./graphics//:'.$ENV{'TEXINPUTS'}; ``` Kpathsea connaîtra désormais les dossiers contenus sous `**graphics**` et grâce à `//` il cherchera aussi dans les sous-dossiers. Notez encore que le deux-points dans `./graphics//:` est en fait *extrêmement* est important. Si vous omettez ce deux-points, TeX/LaTeX risque de ne pas pouvoir trouver des fichiers système essentiels, tels que les paquets LaTeX ! En utilisant l'exemple de projet simple ci-dessus, vous pouvez maintenant le compiler et voilà ! LaTeX trouve votre fichier graphique — et vous pouvez renommer ou réorganiser les dossiers sous /graphics sans empêcher LaTeX de les trouver. ## Tableau répertoriant les « variables de configuration » de Kpathsea Le tableau suivant est un résumé tiré de [des données répertoriées dans la documentation de Kpathsea](http://tug.org/texinfohtml/kpathsea.html#Supported-file-formats). | | | | | --------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------ | | **Variable de configuration Kpathsea** | **Description du type de fichier** | **Extension de fichier** | | AFMFONTS | métriques de police Adobe | .afm | | MFBASES, TEXMFINI | vidage mémoire de Metafont | .base | | BIBINPUTS, TEXBIB | Source bibliographique BibTeX | .bib | | BLTXMLINPUTS | Fichiers bibliographiques BibLaTeXML pour Biber | .bltxml | | BSTINPUTS | Style BibTeX | .bst | | CLUAINPUTS | bibliothèques dynamiques pour Lua | .dll and .so | | CMAPFONTS | fichiers de carte de caractères | .cmap | | TEXMFCNF | Fichiers de configuration à l'exécution | .cnf | | CWEBINPUTS | Fichiers d'entrée CWEB | .w, .web, .ch | | TEXCONFIG | Fichiers « config.\* » de Dvips, comme config.ps | | | ENCFONTS | vecteurs d'encodage | .enc | | TEXFORMATS, TEXMFINI | vidage mémoire de TeX | .fmt | | FONTCIDMAPS | mappage CJK | .cid | | FONTFEATURES | principalement pour les fonctionnalités des polices OpenType | .fea | | FONTS, GFFONTS, GLYPHFONTS, TEXFONTS | bitmap générique de police | .gf | | TEXPICTS, TEXINPUTS | figures PostScript encapsulées | .eps, .epsi | | TEXINDEXSTYLE, INDEXSTYLE | fichiers de style makeindex | .ist | | LIGFONTS | fichiers de définition de ligatures | .lig | | TEXMFDBS | Bases de données de noms de fichiers | | | TEXFONTMAPS | Cartes de polices | .map | | MPMEMS, TEXMFINI | vidage mémoire de MetaPost | .mem | | MPSUPPORT | fichiers de support MetaPost, utilisés par DMP | | | MFINPUTS | source Metafont | .mf | | MFPOOL, TEXMFINI | chaînes de programme Metafont | .pool | | MFTINPUTS | fichier de style MFT | .mft | | MISCFONTS | fichiers liés aux polices qui n'entrent pas dans les autres catégories | | | MLBIBINPUTS, BIBINPUTS, TEXBIB | Source bibliographique MlBibTeX | .mlbib, .mlbib | | MLBSTINPUTS, BSTINPUTS | Style MlBibTeX | .mlbst, .bst | | MPINPUTS | source MetaPost | .mp | | MPPOOL, TEXMFINI | chaînes de programme MetaPost | .pool | | OCPINPUTS | fichiers de processus compilés Omega | .ocp | | OFMFONTS, TEXFONTS | métriques de police Omega | .ofm, .tfm | | OPENTYPEFONTS | polices OpenType | | | OPLFONTS, TEXFONTS | listes de propriétés Omega | .opl | | OTPINPUTS | fichiers de processus de traduction Omega | .otp | | OVFFONTS, TEXFONTS | polices virtuelles Omega | .ovf | | OVPFONTS, TEXFONTS | listes de propriétés virtuelles Omega | .ovp | | PDFTEXCONFIG | fichiers de configuration spécifiques à PDFTeX | | | PROGRAMFONTS, PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS | polices bitmap compactées | .pk | | TEXPSHEADERS, PSHEADERS | PostScript téléchargeable | .pro | | RISINPUTS | fichiers bibliographiques RIS, principalement pour Bibe | .ris | | SFDFONTS | fichiers de définition de sous-polices | .sfd | | TEXINPUTS | source TeX | .tex | | TEXDOCS | Fichiers de documentation du système TeX | | | TEXSOURCES | Fichiers source du système TeX | | | TEXMFSCRIPTS | Exécutables indépendants de l'architecture distribués dans les arbres texmf | | | TEXPOOL, TEXMFINI | chaînes de programme TeX | .pool | | TFMFONTS, TEXFONTS | métriques de police TeX | .tfm | | TRFONTS | polices Troff | | | TTFONTS | Polices vectorielles TrueType | .ttf, ,TTF, .ttc, .TTC, .dfont | | T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS | polices contour PostScript de type 1 | .pfa, .pfb | | T42FONTS | polices contour PostScript de type 42 | | | VFFONTS, TEXFONTS | polices virtuelles | .vf | | WEBINPUTS | fichiers d'entrée WEB | .web, .ch | | WEB2C | fichiers spécifiques à l'implémentation web2c | | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/fr/articles-approfondis/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.