> 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/autres-sujets/18-how-overleaf-created-the-tex-primitive-reference-data.md).

# Comment Overleaf a créé les données de référence des primitives TeX

Cet article décrit les méthodes et techniques utilisées pour produire les deux tableaux de correspondance croisée des commandes primitives de TeX :

* [Primitives de TeX listées par moteur TeX](/latex/fr/autres-sujets/46-tex-primitives-listed-by-tex-engine.md) et ;
* [Primitives de TeX listées par moteur CJK TeX](/latex/fr/autres-sujets/45-tex-primitives-listed-by-cjk-tex-engine.md).

Ces informations sont fournies aux lecteurs intéressés par les détails les plus fins, mais ne sont pas un prérequis pour utiliser le tableau de correspondance croisée lui-même. Pour répondre aux besoins de différents lecteurs, nous proposons une très courte version de résumé/aperçu, ainsi qu’une explication plus longue pour ceux qui souhaitent explorer les questions plus en profondeur.

## Version courte de résumé/aperçu

Pour construire le tableau de correspondance croisée, Overleaf a traité le code source de 9 moteurs TeX afin d’extraire la liste des primitives prises en charge par chacun : ce processus a produit 9 fichiers texte (1 fichier par moteur TeX). Ces 9 ensembles de primitives ont été combinés pour créer une « liste maîtresse », qui était en fait l’union des ensembles individuels de primitives : ce qui a donné un total d’environ 1000 primitives uniques réparties entre les différents moteurs. Pour chaque moteur, sa propre liste de primitives a été mise en correspondance avec le fichier maître (l’ensemble de toutes les commandes) afin de déterminer lesquelles de ces \~1000 commandes il prenait en charge : ces comparaisons sont présentées dans les deux tableaux suivants :

* [Données de correspondance croisée des primitives TeX](/latex/fr/autres-sujets/46-tex-primitives-listed-by-tex-engine.md)
* [Données de correspondance croisée des primitives TeX (pour les moteurs CJK)](/latex/fr/autres-sujets/45-tex-primitives-listed-by-cjk-tex-engine.md)

## « Construire des logiciels » 101 : qu’est-ce que cela signifie ?

Tout au long du reste de cet article, nous faisons référence à la notion de « construire des moteurs TeX », ce qui peut être un concept peu familier si vous n’êtes pas programmeur, ou si vous ne programmez pas dans des langages compilés tels que C ou C++. Pour nos besoins, construire un logiciel — c.-à-d. des moteurs TeX — est le processus consistant à créer un programme TeX exécutable à partir de ses éléments constitutifs, les fichiers de code source écrits dans le langage de programmation utilisé pour développer le programme.

## Version complète : vous voulez les détails ? Lisez la suite...

Chaque moteur de composition typographique basé sur TeX prend en charge un « dialecte » du langage TeX : un ensemble particulier de commandes primitives qui contrôlent les fonctionnalités de composition de chaque moteur et fournissent les éléments de base pour créer/définir des macros : des séquences de commandes définies par l’utilisateur. Toute macro, qu’elle soit écrite pour LaTeX, plain TeX ou tout autre paquet de macros, est en fin de compte construite à partir de commandes primitives — bien que vous deviez parfois remonter assez loin, à travers plusieurs couches de macros supplémentaires, avant d’atteindre la « couche roche-mère » des primitives de TeX. L’ensemble des 9 moteurs TeX analysés pour produire les données de référence des commandes primitives a bien sûr beaucoup de commandes en commun, mais chaque moteur TeX possède aussi ses propres commandes primitives, ajoutées par ses développeurs, afin de prendre en charge les fonctionnalités spécifiques à cette « version » de TeX.

Les commandes primitives d’un moteur TeX sont intégrées au logiciel TeX exécutable : les primitives ne sont pas des macros construites par les utilisateurs, ce sont des instructions fondamentales, indivisibles/atomiques, utilisées pour contrôler le comportement de composition de chaque moteur. Par conséquent, la manière la plus fiable de créer une liste définitive des commandes primitives prises en charge par un moteur TeX consiste à examiner le code source réel à partir duquel les programmes TeX exécutables sont construits (compilés) et à en extraire la liste des primitives définies dans le code source. Cela semble devoir être facile, non ? Cependant, en raison des 40 ans d’histoire du développement de TeX, explorer/examiner les fichiers de code source des moteurs TeX (sauf LuaTeX) n’est pas particulièrement simple. La raison de ces complexités réside dans les outils, le langage de programmation (Pascal) et la méthodologie (programmation lettrée) qu’a utilisés Knuth pour écrire le code source original de TeX — dont tous les autres moteurs descendent, en fin de compte.

Nous notons une exception pour LuaTeX, car le code de son moteur principal a été réécrit en C afin d’éliminer l’utilisation de Pascal et d’autres complexités héritées détaillées ci-dessous (Web2C) ; par conséquent, bien que le code source de LuaTeX soit conséquent, la manière dont il est « empaqueté » et distribué est beaucoup plus compréhensible que pour les autres moteurs TeX. En conséquence, et compte tenu du flux de travail/des processus utilisés pour les construire à partir du code source, il est pratique de regrouper les moteurs TeX en deux catégories :

1. LuaTeX : processus de compilation personnalisé (plus moderne)
2. Tous les autres moteurs : processus de compilation hérité (Web2C)

## Le contexte du code hérité : pourquoi construire (la plupart des) moteurs TeX est complexe

Comme nous le verrons ci-dessous, Knuth a publié le code source original de TeX sous la forme d’un fichier unique et monolithique appelé `tex.web` qu’il continue de mettre à jour tous les 7 ans pour corriger les bogues restants — aucune nouvelle fonctionnalité n’est jamais ajoutée, il s’agit uniquement d’un exercice de correction de bogues.

L’extension du code source de TeX (`.web`) n’est probablement pas familière et vous vous demandez peut-être dans quel langage Knuth a écrit TeX ? La réponse est Pascal, mais l `.web` extension a besoin de quelques explications supplémentaires. Knuth a développé une méthodologie de programmation qu’il a appelée [programmation lettrée](https://en.wikipedia.org/wiki/Literate_programming) dans laquelle le code source d’un programme et sa documentation sont combinés et publiés sous la forme d’un seul fichier composite (code + documentation) avec l’extension `.web`: ce type de fichier est appelé fichier WEB. Nous expliquons les fichiers WEB un peu plus en détail ci-dessous.

### Créer de nouveaux moteurs TeX : les stipulations de Knuth

Bien que Knuth ait depuis longtemps rendu son code source TeX (`tex.web`) librement disponible pour tous, il a, comme c’est son droit absolu, posé une condition essentielle : son code source (`tex.web`) ne doit pas être directement modifié/édité puis redistribué sous le nom de programme « TeX ». Dans le code source, il écrit :

```
% Ce programme est protégé par le droit d’auteur (C) 1982 par D. E. Knuth ; tous droits réservés.
% La copie de ce fichier n’est autorisée que si (1) vous êtes D. E. Knuth, ou si
% (2) vous n’apportez absolument aucune modification à votre copie. (Le système WEB fournit
% des modifications via un fichier auxiliaire ; le fichier maître doit rester intact.)
```

et aussi :

```
Si ce programme est modifié, le système résultant ne doit pas être appelé
`\TeX' ; le nom officiel `\TeX' lui-même est réservé
aux systèmes logiciels qui sont pleinement compatibles entre eux.
Une suite de tests spéciale appelée le « test \.{TRIP} » est disponible pour
aider à déterminer si une implémentation particulière mérite d’être
appelée `\TeX' [cf. rapport CS1027 de Stanford Computer Science,
novembre 1984].
```

En substance : ne faites pas de modifications en éditant et en distribuant des versions modifiées du code source maître de TeX et continuez à l’appeler `tex.web`. Si vous souhaitez apporter des modifications, par exemple ajouter de nouvelles primitives, etc., alors vous devez appliquer ces changements en faisant des « modifications via un fichier auxiliaire » et donner à votre programme « dérivé de TeX » un nom qui le distingue de « TeX », lequel, sous sa forme typographique ($$\mathrm\TeX$$), est une marque déposée de l’American Mathematical Society.

### L’héritage du code hérité

Bien qu’il y ait eu des tentatives de réécrire complètement TeX à l’aide de langages et de méthodologies de programmation modernes — comme les deux initiatives basées sur Java [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) et [εχTEX](http://www.extex.org/) et d’autres telles que [une en Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure), aucune n’a été complètement couronnée de succès. L’histoire des projets et initiatives conçus pour faire évoluer TeX est un sujet intéressant et les lecteurs souhaiteront peut-être [consulter la FAQ TeX du Royaume-Uni](https://texfaq.org/FAQ-enginedev) pour plus d’informations.

Ces initiatives non LuaTeX qui ont elles aussi rencontré le succès, comme e-TeX, pdfTeX, XeTeX et d’autres moteurs, ont été construites *directement au-dessus* du code original de Knuth : en prenant son code source et en « appliquant des modifications » pour en dériver un nouveau moteur doté de capacités supplémentaires — comme l’ajout de nouvelles primitives, la production de sortie PDF, la prise en charge de l’entrée de texte UTF-8, etc. Bien que cette voie ait conduit à des succès notables, elle signifie aussi que ces moteurs dérivés héritent du code hérité et des techniques de développement que Knuth a créées il y a 40 ans.

L’idée essentielle ici est que, mis à part LuaTeX, la plupart des moteurs TeX dérivés du code source original de Knuth sont créés en prenant un seul fichier monolithique (généralement `tex.web`) et en appliquant des modifications qui génèrent encore un autre fichier monolithique unique contenant le code source principal de ce nouveau moteur. Les lecteurs avancés souhaiteront peut-être passer directement aux [notes explicatives sur pdfTeX et XeTeX](#aside-xetex-and-pdftex).

### Quelques éléments supplémentaires d’histoire/contexte de TeX

Le moment de la genèse de TeX a été [consigné dans le journal de Knuth comme étant le 30 mars 1977](/latex/fr/articles-approfondis/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), il y a maintenant plus de 40 ans. En interne, TeX est un programme extraordinairement complexe dont Knuth a pris grand soin de [documenter avec un niveau de détail exceptionnel](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). Pour cela, Knuth a développé un style de programmation qu’il a appelé [programmation lettrée](https://en.wikipedia.org/wiki/Literate_programming) dans lequel le code source d’un programme et sa documentation sont combinés et publiés sous la forme d’un fichier composite avec l’extension `.web` (appelé fichier WEB). Knuth a choisi Pascal comme langage de programmation pour écrire son logiciel TeX et, sans surprise, a utilisé le langage de composition typographique TeX pour rédiger la documentation finale. Par conséquent, le code source maître de TeX de Knuth est publié sous la forme d’un seul fichier monolithique appelé `tex.web`: un mélange de code source Pascal et de code de composition typographique TeX pour la documentation.

Si un programme est écrit en utilisant le style/la méthodologie de programmation lettrée de Knuth (comme c’est le cas pour TeX, MetaFont, BibTeX et d’autres), vous devez prétraiter le fichier WEB pour en extraire la documentation ou le code source. Pour accéder à la documentation du programme, vous traitez le fichier WEB (par exemple, `tex.web`) avec un utilitaire appelé [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) qui produit la documentation sous forme de `.tex` fichier que vous pouvez mettre en page. Pour extraire le code source en Pascal, vous utilisez un autre utilitaire appelé [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) qui génère un fichier avec l’extension `.p` contenant du code source Pascal.

Au moment de la rédaction (début 2019), la dernière version de TeX de Knuth est la 3.14159265, datée de janvier 2014. Là encore, notez que le code source de TeX de Knuth tient dans un seul fichier contenant environ 25 000 lignes de code TeX/Pascal !

### Du Pascal vers le C

Au cours des plus de 40 années écoulées depuis la naissance de TeX, Pascal est passé de mode et aujourd’hui peu de gens, voire personne ?, envisagent de construire TeX à partir de son code source Pascal d’origine. Pour contourner l’utilisation de Pascal par Knuth, un flux de travail appelé [Web2C](http://tug.org/texinfohtml/web2c.html) a été conçu (vers 1987) : le code source Pascal de TeX est converti mécaniquement (c.-à-d. par logiciel) en son équivalent en code C, qui est ensuite utilisé pour compiler TeX et construire le programme exécutable. Cela fonctionne bien, mais l’inconvénient est que le code source C généré mécaniquement n’est pas destiné à une inspection humaine occasionnelle : il est *extrêmement* verbeux et presque impénétrable, étant destiné aux compilateurs et non aux personnes — voici une capture d’écran montrant un petit extrait du code C généré à partir du code source Pascal de TeX :

![](/files/b5344f1bf7252327a84146edd4fa3ab9cc183ca3)

### Autre idée de Knuth : les fichiers de modification WEB

Comme indiqué ci-dessus, pour développer à partir du code source original de Knuth, vous « appliquez des modifications » ou, selon les mots de Knuth, vous faites des « modifications via un fichier auxiliaire » : mais qu’est-ce que cela signifie concrètement ? Voici le *mécanisme des fichiers de modification*.

### Fichiers de modification : le mécanisme de création de nouveaux moteurs TeX

Les développeurs qui souhaitent étendre TeX de Knuth d’une manière ou d’une autre, c’est-à-dire s’appuyer sur le travail original de Knuth, veulent généralement créer une toute nouvelle « version » de TeX ou fournir une *extension* qui peut être ajoutée à n’importe quel moteur TeX. Parmi les exemples d’extensions, on trouve [SyncTeX](https://github.com/jlaurens/synctex) et [EncTeX](https://ctan.org/pkg/enctex?lang=en)— SyncTeX, par exemple, est une extension très utile qui est désormais incluse dans tous les moteurs TeX. Le besoin d’EncTeX a été en grande partie supplanté par l’évolution des moteurs TeX compatibles Unicode — mais notez qu’EncTeX est intégré à pdfTeX.

Que le souhait soit de produire une nouvelle « version » de TeX (c.-à-d. un dérivé du TeX original de Knuth) ou de créer une extension, ses développeurs partent du code source original de Knuth et appliquent les modifications nécessaires pour créer un nouveau moteur TeX (ou une extension ajoutable). Cependant, comme indiqué ci-dessus, quiconque souhaite modifier le comportement de TeX doit le faire en utilisant des « modifications via un fichier auxiliaire », car ces changements/modifications ne doivent pas être appliqués en *éditant* directement le code source original de Knuth : les développeurs sont tenus d’utiliser le WEB dit *mécanisme des fichiers de modification*. Le code permettant de modifier TeX de Knuth est écrit dans le « langage » WEB et enregistré dans un ou plusieurs fichiers de code (appelés *fichiers de modification*) qui sont ensuite *fusionnés* avec le code source maître original et intact de Knuth. Ce processus de fusion crée un nouveau fichier WEB composite qui contient maintenant le *code* source principal du nouveau logiciel basé sur TeX, ou du logiciel TeX modifié. *Les fichiers de modification* ont souvent l’extension `.ch` mais en pratique, ils peuvent avoir n’importe quelle extension souhaitée par les développeurs.

#### Comment utiliser/appliquer les fichiers de modification ?

De nos jours, le moyen le plus simple d’appliquer des fichiers de modification et de modifier un fichier WEB « maître » consiste à utiliser un programme utilitaire appelé [TIE](https://ctan.org/pkg/tie). Par exemple, supposons que vous souhaitiez modifier TeX de Knuth en ajoutant, disons, quelques nouvelles primitives, ou que vous souhaitiez changer le comportement d’une primitive TeX (standard) existante. Vous écririez votre code (en Pascal !) en utilisant le système WEB de programmation lettrée et l’enregistreriez dans un fichier appelé, par exemple, `myprim.ch`. L’étape suivante consiste à fusionner votre code (dans `myprim.ch`) avec le fichier source maître de Knuth `tex.web` et à produire un nouveau fichier WEB composite représentant ce que nous appellerons `mytex.web`. Pour ce faire, il suffit d’exécuter le programme TIE comme ceci :

```
tie -m mytex.web tex.web myprim.ch
```

En supposant que la fusion réussisse, cela donnera un nouveau fichier WEB, `mytex.web`en laissant le fichier source maître de Knuth `tex.web` entièrement inchangé, comme requis.

Supposons maintenant que quelqu’un d’autre apprécie les modifications que vous avez apportées et souhaite modifier votre travail pour ajouter ses changements par-dessus, ou en plus, de ce que vous avez fait. Plutôt que de distribuer votre version modifiée de TeX (`mytex.web`) vous décidez de ne publier/partager que le fichier de modification, `myprim.ch`. Toute personne souhaitant développer votre travail peut désormais créer et partager son propre fichier de modification appelé, par exemple, `moreprim.ch` qui étend votre code d’une manière ou d’une autre. Quiconque souhaite désormais tirer parti des deux fichiers de modification peut générer un nouveau fichier WEB composite en fusionnant *les deux* fichiers de modification dans l’original de Knuth afin de générer encore un autre programme TeX appelé, par exemple, `newmytex.web`:

```
tie -m newmytex.web tex.web myprim.ch moreprim.ch
```

### Vrais systèmes TeX : plusieurs fichiers de modification

La description ci-dessus de TIE est en fait très proche de la manière dont de nombreux moteurs TeX sont construits en pratique : ils commencent avec le `tex.web` de Knuth et ajoutent une succession de fichiers de modification pour générer le fichier source WEB de ce moteur. Chaque moteur TeX nécessite son propre ensemble particulier de fichiers de modification, qui doivent être appliqués/traités (fusionnés) dans un ordre strict : si l’ordre est incorrect, le processus de fusion échouera, car chaque fichier de modification d’une séquence repose sur les changements introduits par les fichiers de modification apparaissant plus tôt dans la chaîne.

Voici un exemple d’exécution de TIE appliquant plusieurs fichiers de modification au `tex.web` de Knuth afin de générer `ktex.web`— le fichier WEB composite avec les modifications apportées au TeX de Knuth qui le rendent prêt (adapté) à la conversion en C via le processus Web2C. Notez également ce qui suit :

* `tex.ch` est un très grand fichier de modification qui, entre autres, modifie TeX pour utiliser Kpathsea ;
* l’extension SyncTeX est ajoutée via plusieurs fichiers de modification.

```
tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch
Voici TIE, version 2.4 de CWEB.
Copyright (c) 1989,1992 par THD/ITI. Tous droits réservés.
(tex.web)
(tex.ch)
(enctex.ch)
(synctex-def.ch0)
(synctex-mem.ch0)
(synctex-mem.ch2)
(synctex-rec.ch0)
(synctex-rec.ch1)
(synctex-rec.ch2)
(tex-binpool.ch)
....500....1000....1500....2000....2500....3000....3500....4000....4500
....5000....5500....6000....6500....7000....7500....8000....8500....9000
....9500....10000....10500....11000....11500....12000....12500....13000
....13500....14000....14500....15000....15500....16000....16500....17000
....17500....18000....18500....19000....19500....20000....20500....21000
....21500....22000....22500....23000....23500....24000....24500....
(Aucune erreur n’a été trouvée.)
```

#### À part : XeTeX et pdfTeX

Pour être complet, nous devons noter que le processus de compilation de pdfTeX et XeTeX ne commence pas réellement avec le `tex.web`de Knuth ; ils commencent plutôt avec des fichiers appelés `pdftex.web` et `xetex.web` respectivement : probablement parce que les modifications sont si importantes qu’il est plus logique de partager/publier des fichiers WEB contenant déjà les modifications très substantielles apportées au code original de Knuth.

### Un exemple : e-upTeX

La communauté japonaise de TeX a développé un certain nombre de moteurs TeX conçus pour répondre aux complexités de la composition du texte japonais :

* **pTeX**: moteur TeX de Knuth étendu pour prendre en charge la composition japonaise ;
* **e-pTeX**: une combinaison de e-TeX et de pTeX (plus quelques primitives introduites par pdfTeX) ;
* **upTeX**: une version de pTeX compatible Unicode, plus des extensions pour une meilleure prise en charge des CJK (chinois, japonais et coréen) ;
* **e-upTeX**: une combinaison (fusion) de e-TeX et upTeX.

#### Génération du fichier source composite pour e-upTeX

Pour créer le fichier source WEB composite pour e-upTeX (avec SyncTeX), vous commencez avec le `tex.web` de Knuth, mais devez appliquer **26** des fichiers de modification individuels, dans l’ordre suivant, afin d’obtenir un fichier composite unique à partir duquel la liste des commandes primitives peut être extraite :

```
etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0,
ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech,
etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0,
synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1,
synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1,
synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch,
pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch,
tex-binpool.ch
```

#### Application des fichiers de modification : quels fichiers et dans quel ordre ?

Comme indiqué, il est d’une importance cruciale d’appliquer/traiter les fichiers de modification dans un ordre strict — mais comment savoir quels fichiers sont nécessaires et dans quel ordre les traiter ? Heureusement, cette information cruciale est consignée dans des fichiers contenus dans la distribution TeX Live, et l’exploration du code source de TeX Live a révélé les règles qui régissent les exigences de compilation pour chaque moteur TeX. En suivant ces règles, Overleaf a pu reconstituer le fichier source WEB composite de chaque moteur TeX et extraire une liste de primitives pour le traitement ultérieur des données.

## Et enfin : comment extraire la liste des primitives ?

Une fois le fichier WEB composite construit, la tâche d’extraction de la liste des primitives, à l’aide d’expressions régulières, est simple, car toutes les commandes primitives sont définies (« enregistrées ») à l’aide d’une unique fonction Pascal appelée `primitive(...)`. Voici quelques exemples réels tirés du code source de `tex.web` :

```
primitive("lineskip",assign_glue,glue_base+line_skip_code)
primitive("baselineskip",assign_glue,glue_base+baseline_skip_code)
primitive("parskip",assign_glue,glue_base+par_skip_code)
primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code)
primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code)
primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code)
...
...
```

Comme vous pouvez le voir, la `primitive(...)` fonction se prête très bien au traitement textuel avec des expressions régulières : le nom de la primitive en cours d’enregistrement est entre guillemets (`"..."`) avec des données supplémentaires qui classent le comportement de chaque primitive (nous n’en tiendrons pas compte en détail). Après avoir extrait la liste des primitives pour chaque moteur, ces données ont été traitées par quelques scripts Lua pour générer un HTML contenant les résultats sous forme de tableau.

### Retour à LuaTeX

Nous avons noté que LuaTeX n’utilise pas exactement les mêmes processus de compilation que les 8 autres moteurs TeX. Après avoir brièvement exploré le processus Web2C, la conversion de Pascal en C et le mécanisme des fichiers de modification, nous pouvons maintenant expliquer en quoi LuaTeX diffère : les développeurs de LuaTeX ont décidé de se passer du fastidieux processus de conversion de Pascal en C — comme indiqué dans [Le manuel de référence de LuaTeX](http://www.pragma-ade.com/general/manuals/luatex):

> ... le cadre de compilation est web2c et nous continuons à l’utiliser mais sans l’étape Pascal vers C.

Le moteur principal de LuaTeX a été réécrit en C, ce qui signifie que son processus de compilation est un peu plus standard et certainement beaucoup plus pratique. Une conséquence utile est que les primitives prises en charge par LuaTeX sont clairement isolées dans un fichier source C distinct, ce qui a considérablement facilité la tâche consistant à y accéder/les lister.

À proprement parler, nous devons aussi noter que certains fichiers source de LuaTeX utilisent une variante de la méthodologie de programmation lettrée de Knuth, appelée [CWEB](https://en.wikipedia.org/wiki/CWEB), qui est basée sur C et non sur Pascal.

### Pas seulement des fichiers WEB : d’autres codes source sont nécessaires

Après avoir généré le fichier source WEB composite pour n’importe quel moteur TeX (sauf LuaTeX), le code source Pascal doit être extrait et converti en code C, mais cela ne constitue pas la solution totale. En plus du code C généré à partir du source WEB (Pascal⮕C), la plupart des moteurs TeX s’appuient également (nécessitent) sur un certain nombre de fichiers source auxiliaires supplémentaires (bibliothèques) généralement écrits en C — comme [Kpathsea](https://www.tug.org/kpathsea/). Les fichiers source auxiliaires (bibliothèques) implémentent des fonctionnalités qui n’ont pas besoin, ou ne peuvent pas, être écrites en WEB (Pascal). Tout ce qui est écrit dans le « langage » WEB pour TeX doit utiliser le langage Pascal, qui est ensuite extrait et converti en C généré par machine : si vous n’avez pas besoin de faire cela, pourquoi ne pas simplement l’écrire d’emblée en C ou en C++.


---

# 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/autres-sujets/18-how-overleaf-created-the-tex-primitive-reference-data.md?ask=<question>&goal=<endgoal>
```

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