> 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/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md). # Introduction à LuaTeX (partie 1) : qu’est-ce que c’est — et qu’est-ce qui le rend si différent ? LuaTeX est une *boîte à outils*—elle contient des outils et des composants logiciels sophistiqués grâce auxquels vous pouvez construire (mettre en page) une vaste gamme de documents. Le sous-titre de cet article pose également deux questions sur LuaTeX : qu’est-ce que c’est — et qu’est-ce qui le rend si différent ? La réponse à « Qu’est-ce que c’est ? » peut sembler évidente : « C’est un moteur de composition TeX ! » En effet, c’en est un, mais une vision plus large, et à laquelle l’auteur adhère, est que LuaTeX est un système fondé sur TeX extrêmement polyvalent *système de construction et d’ingénierie de documents*. ### Expliquer LuaTeX : par où commencer ? Le but de ce premier article sur LuaTeX est de proposer un contexte permettant de comprendre ce que fournit ce moteur TeX et pourquoi/comment sa conception permet aux utilisateurs de construire/concevoir/créer une vaste gamme de solutions à des problèmes complexes de composition et de conception — offrant peut-être aussi une certaine « pérennité » à mesure que les utilisateurs ont de plus en plus besoin de logiciels fondés sur TeX capables de s’adapter à un écosystème technique en constante évolution. À mon avis, énumérer et décrire ses fonctionnalités/capacités n’est pas nécessairement le meilleur point de départ pour se familiariser avec les capacités et le potentiel de LuaTeX. Une telle approche ne sera pas particulièrement utile pour les lecteurs qui ne connaissent pas d’autres moteurs TeX et pour qui les comparaisons fondées sur les fonctionnalités sont peu susceptibles d’avoir une signification particulière. Au risque d’épuiser la patience du lecteur (« Allez droit au but ! »), j’adopterai une approche plus « holistique », en espérant fournir un contexte utile, mais au prix d’une lecture supplémentaire — et en m’aventurant dans quelques sujets de programmation pour faciliter la compréhension. Dans [Partie 2](/latex/fr/articles-approfondis/09-an-introduction-to-luatex-part-2-understanding-directlua.md) nous explorons l’utilisation de `\directlua` mais, pour l’instant, nous nous efforçons de poser les bases nécessaires à la compréhension de LuaTeX. Cet article reflète fortement le parcours personnel de l’auteur dans sa compréhension et son appréciation de LuaTeX : savoir d’abord quelque chose de la philosophie qui sous-tend le développement de LuaTeX, et le voir comme un conteneur d’outils logiciels, vous permettra mieux d’apprécier les vastes domaines de solutions ouverts par ce logiciel étonnant. ## LuaTeX : pas seulement pour le milieu universitaire, ou les mathématiques ! La richesse des fonctionnalités intégrées à LuaTeX fournit non seulement une composition de qualité exceptionnellement élevée via le LaTeX traditionnel, mais offre aussi un immense champ de possibilités pour développer des solutions sur mesure, non fondées sur LaTeX, à des problèmes complexes de production et d’ingénierie documentaire. LuaTeX intègre le puissant langage de script Lua, ce qui signifie, par exemple, que vous pouvez utiliser Lua pour charger des « plugins » (bibliothèques logicielles externes) dans LuaTeX ; cela permet en outre un haut niveau d’automatisation, l’intégration dans des systèmes ou flux de travail logiciels existants et l’exploitation de logiciels spécialisés pour le traitement des données, du texte ou des graphiques. Historiquement, TeX a été associé à l’écriture et à l’édition savantes, notamment en mathématiques, mais LuaTeX, en particulier, présente un potentiel important pour des applications dans de nombreux autres domaines — y compris la production commerciale de documents PDF. Un tel exemple est [speedata publisher](https://speedata.github.io/publisher/) qui utilise LuaTeX uniquement comme moteur de génération de PDF dans son flux de travail fondé sur XML — il n’utilise pas LaTeX du tout. En effet, speedata publisher ne contient pratiquement aucun code TeX — j’ai demandé à [Patrick Gundlach](https://twitter.com/patrickgundlach), le développeur de speedata publisher, qui a confirmé qu’au total, le logiciel n’utilise qu’environ trois lignes de code TeX. Ses puissantes capacités de composition sont conçues et implémentées en code Lua, en utilisant l’API Lua de LuaTeX (un sujet que nous abordons plus loin dans cet article). ## Une courte histoire personnelle : comment j’ai découvert LuaTeX pour la première fois J’ai découvert LuaTeX fin 2009 / début 2010, lorsqu’il en était encore au stade de préversion bêta intermédiaire (version 0.50). À l’époque, je cherchais un logiciel fondé sur TeX pour mettre en page les notes manuscrites résultant de mes efforts pour apprendre un peu d’arabe. Des recherches Google ont révélé une série de vidéos de la conférence TUG 2009 ([désormais sur YouTube](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)) qui comprenaient des démonstrations de composition de l’arabe d’une très grande qualité (via le [package ConTeXt](http://wiki.contextgarden.net/Main_Page)). Ces vidéos comprennent également une conférence intitulée [Le projet LuaTeX : à mi-chemin vers la version 1](https://youtu.be/AKv4po9PGW0). Le moteur TeX utilisé pour produire cette exquise composition arabe était quelque chose appelé « LuaTeX ». À l’époque, je travaillais dans l’édition scientifique (physique), mais bien que parfaitement conscient de TeX/LaTeX, je n’avais jamais entendu parler de LuaTeX : j’étais intrigué et voulais en savoir plus sur ce nouveau moteur TeX. Comme LuaTeX était encore au stade de développement bêta, et en pleine évolution rapide, je voulais rester à jour avec les toutes dernières nouveautés ; la meilleure option (pour moi) était donc la voie du bricolage, à savoir construire (compiler) l’exécutable LuaTeX à partir de son code source. En plus du programme exécutable LuaTeX, vous avez également besoin d’une « installation TeX » pour fournir l’environnement dans lequel exécuter LuaTeX (par exemple texmf.cnf, paquets de macros, polices, etc.). Plutôt que de télécharger et d’installer l’énorme [TeX Live](https://www.tug.org/texlive/) distribution, j’ai choisi de créer une installation TeX personnalisée absolument minimale avec laquelle explorer LuaTeX (un exercice « intéressant » que j’ai [documenté sur mon blog personnel](http://www.readytext.co.uk/?cat=30)). Chaque nouvelle version de LuaTeX s’accompagne de son manuel de référence (par exemple, pour[la version 1.0.4](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co)) qui documente les fonctionnalités et capacités les plus récentes du logiciel. Cependant, il s’agit d’un *manuel de référence* et (nécessairement) plutôt pauvre en explications destinées au débutant qui souhaite se lancer avec cet incroyable moteur TeX — on suppose un certain degré de familiarité avec les concepts bas niveau de TeX. Étant donné que j’avais découvert LuaTeX à un stade relativement précoce de son développement, de bons documents d’introduction étaient, à cette époque, relativement difficiles à trouver ; il m’a donc fallu un peu d’exploration, d’expérimentation (et de frustration…) avant que tout commence à s’assembler. Inutile de dire que mes études d’arabe se sont brutalement interrompues à mesure que je devenais fasciné par ce logiciel étonnant et que je me suis finalement mis à écrire des [plugins LuaTeX pour la composition de l’arabe](http://www.readytext.co.uk/?p=3143) à la place ! Mon propre « parcours LuaTeX » a certes été très non linéaire, mais, au fil du chemin, il m’a donné l’occasion d’apprendre (Lua)TeX (et les installations TeX) « depuis la base » : mon blog héberge une collection éclectique de [articles](http://www.readytext.co.uk/?cat=3) fondée sur divers sujets que j’ai explorés et sur lesquels j’ai travaillé durant cette période. J’espère que cet article fait un usage approprié de ce temps et de cette expérience, en aidant d’autres personnes à s’intéresser à l’exploration des capacités de LuaTeX. LuaTeX continue d’être développé et, au moment où j’écris ces lignes, il est arrivé à la version 1.0.4, publiée avec TeX Live 2017. Les développeurs sont très actifs et les bogues découverts sont généralement corrigés peu après avoir été signalés — par exemple via la [liste de diffusion dev-luatex](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) ou via le [traqueur de bogues LuaTeX en ligne](http://tracker.luatex.org/my_view_page.php). Bien avant d’atteindre la version 1.0, LuaTeX était déjà utilisable en production — même s’il fallait bien sûr accepter que les fonctionnalités évoluent continuellement et que, parfois, des changements puissent casser votre code TeX existant. Aujourd’hui, LuaTeX est bien sûr pris en charge par les plateformes Overleaf et ShareLaTeX (sous le nom de LuaLaTeX). ## TeX dans un monde en mutation : nouvelles technologies et nouveaux flux de travail Il est clair que les moteurs TeX n’évoluent pas dans un monde technologiquement figé et que, parfois, des innovations apparaissent comme des candidates immédiates et évidentes à l’intégration dans les moteurs TeX — l’une de ces innovations est celle des polices OpenType variables, que nous abordons brièvement ci-dessous. Bien qu’il n’y ait guère de doute que les logiciels de composition fondés sur TeX soient extraordinairement polyvalents, les moteurs TeX fonctionnent désormais au sein d’un écosystème logiciel en évolution rapide et très diversifié — de nouveaux flux de travail accentuent le besoin d’intégration et de flexibilité pour mettre en œuvre un large éventail de solutions de document/composition, dont TeX n’est peut-être qu’un composant. TeX doit non seulement rester pertinent pour ses utilisateurs actuels, mais aussi en attirer de nouveaux, en permettant des solutions de création de contenu qui restent utiles aux générations montantes — des personnes qui ne voudront peut-être pas nécessairement utiliser TeX comme outil autonome, mais plutôt comme une partie d’un flux de travail global via des plateformes collaboratives en ligne comme Overleaf. Même un simple coup d’œil à [tex.stackexchange](https://tex.stackexchange.com/) montre l’énorme variété de documents et de solutions produits et mis en œuvre avec des logiciels fondés sur TeX — montrant souvent une ingéniosité incroyable, à mesure que les gens trouvent toujours plus de cas d’usage et de types de contenu qu’ils souhaitent générer. En outre, le besoin de flux de travail capables de traiter du balisage/du contenu fondé sur TeX afin de produire des sorties non PDF (et non DVI) n’a jamais été aussi grand — comme MathML/XML et HTML. Par exemple, « convertir » TeX au format [JATS XML](https://jats.nlm.nih.gov/) (longtemps utilisé dans l’édition de revues universitaires), mais aussi, plus récemment, l’essor de l’epub utilisé dans l’édition de livres électroniques. ### Technologie des polices variables — Les temps changent Le 14 septembre 2016, Microsoft, [Google](https://opensource.googleblog.com/2016/09/introducing-opentype-font-variations.html), [Adobe](https://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind-of-font-for-flexible-design/) et Apple ont annoncé une nouvelle technologie de police : [les polices OpenType variables](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). Nous n’explorerons pas cette technologie en détail, mais il suffit de dire que des experts très respectés en polices, tels que [Thomas Phinney](https://twitter.com/ThomasPhinney) et [John Hudson](https://twitter.com/TiroTypeworks) ont observé ([sur Twitter](https://twitter.com/ThomasPhinney/status/917087509342851072)) que la technologie des polices variables est adoptée beaucoup plus rapidement que beaucoup d’innovations typographiques antérieures — très probablement sous l’impulsion des besoins des concepteurs web qui exigent des conceptions réactives s’adaptant aux myriades de tailles/résolutions d’écran différentes présentes sur les appareils mobiles. Il est clair que les polices OpenType variables constituent une évolution intéressante et enthousiasmante des technologies typographiques, dont les utilisateurs de TeX pourraient sans aucun doute tirer profit — en effet, cette question a inévitablement été [soulevée sur tex.stackexchange](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) avec la prise en charge de LuaTeX discutée sur la [liste de diffusion LuaTeX](https://www.tug.org/pipermail/luatex/2016-September/006204.html). Au passage, il convient de noter que la technologie typographique fondée sur la création « paramétrique » de polices n’est pas une idée entièrement nouvelle : METAFONT de Knuth et les technologies Multiple Master d’Adobe sont, à certains égards, des précurseurs initiaux, même si les détails de mise en œuvre sont assez différents. ### Polices variables : quand les voulons-nous — maintenant ? Toute nouvelle norme/spécification technologique utile a besoin de temps pour s’intégrer à l’écosystème cible des développeurs et des implémenteurs — y compris le temps de lever toute ambiguïté ou toute interprétation des formulations de la spécification elle-même. Les développeurs doivent lire et comprendre la documentation, puis la transformer en logiciel réellement fonctionnel — ce qui, ici, comprend la création des polices et des technologies permettant de les utiliser : navigateurs et moteurs de composition compatibles. Les développeurs TeX auront clairement besoin d’accéder à des polices variables de haute qualité qui pourront servir de « références » fiables pour implémenter (programmer) la prise en charge des technologies de polices variables. L’implémentation de toute nouvelle technologie dans TeX, comme les polices variables, soulève le *besoin potentiel* de modifier les entrailles des moteurs TeX — bien sûr, la nécessité de le faire dépend de la nature de cette technologie et, surtout, de l’aspect du comportement de TeX qui doit être modifié. Il n’est pas toujours nécessaire de modifier les moteurs TeX eux-mêmes ; il suffit parfois de changer des logiciels de support/annexes, y compris les « composants » (bibliothèques tierces de code) utilisés dans ces programmes. En interne, les moteurs TeX sont *diaboliquement* complexes — acquérir une compréhension du code source de TeX suffisante pour effectuer des modifications fiables exige une expertise considérable et hautement spécialisée (dont l’offre est très limitée). Il est également essentiel que les modifications n’affectent pas négativement la stabilité/la compatibilité à long terme des moteurs TeX — ce qui est vital pour la communauté TeX et pour ceux qui traitent ensuite le(s) fichier(s) (La)TeX d’un auteur : en particulier les éditeurs académiques et les services cloud tels qu’Overleaf et ShareLaTeX. Beaucoup d’utilisateurs de TeX voudront sans doute exploiter les polices variables ; par exemple, pour mettre en œuvre de nouvelles possibilités de conception ou trouver des solutions à des problèmes de composition délicats. Donc, d’une certaine manière, il y a un dilemme : des utilisateurs de TeX qui veulent accéder à une nouvelle technologie, mais dont l’implémentation dépend d’une ressource très limitée : le nombre de développeurs qualifiés et capables de la réaliser. Modifier les entrailles de TeX est difficile et, en général, il vaut mieux éviter de le faire dans la mesure du possible ; existe-t-il donc une autre manière d’aborder l’ajout de (certaines classes de) nouvelles fonctionnalités/capacités à TeX ? Oui ! et LuaTeX a pris cette voie. #### Premières expériences : polices OpenType variables et LuaTeX La conception de LuaTeX a permis une expérimentation rapide de la technologie des polices variables. Déjà, en avril 2017, le format TeX ConTeXt, qui utilise LuaTeX, disposait d’une [version bêta](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) qui implémentait les polices OpenType variables. Cela était possible parce que la prise en charge des polices dans ConTeXt est construite en code Lua (et que ConTeXt possède son propre chargeur de polices écrit en Lua). ## LuaTeX : contexte et histoire LuaTeX est, en termes TeX, « le petit nouveau » malgré plus de 10 ans de développement actif. Le site web de LuaTeX [documente](http://www.luatex.org/roadmap.html) que LuaTeX a commencé à exister en 2005, avec (je crois) un développement actif et soutenu débutant en 2006. En raison de sa complexité intrinsèque, et du soin apporté par ceux qui l’ont construit, LuaTeX a réellement nécessité 10 ans de développement pour atteindre la version 1.0, qui a été [annoncée par ses développeurs](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) le 27 septembre 2016. Dans cette annonce de publication figure une importante déclaration de principe : > « Notre principal objectif est de fournir une variante de TeX qui autorise les extensions utilisateur sans qu’il soit nécessaire d’adapter le fonctionnement interne. » Cette formulation résume parfaitement la philosophie qui sous-tend le développement de LuaTeX et indique une voie par laquelle les logiciels fondés sur TeX peuvent relever les défis que nous avons déjà mentionnés : adopter de nouvelles technologies et rester pertinents pour les nouvelles générations d’utilisateurs. Il est maintenant temps d’aborder la deuxième question contenue dans le sous-titre de cet article : « qu’est-ce qui le rend si différent ». En explorant le sens de « ... autorise les extensions utilisateur sans qu’il soit nécessaire d’adapter le fonctionnement interne », nous pouvons mieux comprendre l’essence de ce que LuaTeX « apporte à la table ». ## LuaTeX : ouvrir la « boîte noire » de TeX Le programme TeX original de Knuth est l’ancêtre commun de tous les moteurs TeX modernes utilisés aujourd’hui, et LuaTeX est, en effet, la dernière étape évolutive : dérivé du programme pdfTeX, mais avec l’ajout de composants logiciels puissants qui apportent une grande quantité de fonctionnalités supplémentaires. Lorsque Knuth a écrit la version originale du logiciel TeX, il a également fourni le langage TeX comme moyen de contrôler et de programmer son comportement de composition : quelque 320 commandes de bas niveau (primitives) ont été mises à la disposition des utilisateurs et des développeurs de paquets de macros TeX. Ces commandes offraient divers degrés de contrôle ou d’influence sur certains aspects du comportement de composition de TeX, mais une grande partie des fonctionnalités internes de TeX, de ses algorithmes, de ses processus décisionnels, de ses données et de ses structures de données restaient cachées à l’utilisateur. On peut soutenir que le programme TeX de Knuth n’était pas totalement une « boîte noire », mais certainement une nuance très sombre de gris — certes, le code source était disponible, mais, pour l’immense majorité des gens, c’est aussi une boîte noire d’incompréhensibilité. Nous appelons les processus internes de TeX une sorte de « boîte noire » ; cependant, LuaTeX ouvre ses entrailles fondées sur TeX afin d’offrir aux utilisateurs/développeurs un accès bien plus large à de nombreux processus autrefois cachés qui se déroulent au plus profond du moteur TeX, ainsi qu’un contrôle accru sur eux. LuaTeX ajoute également de nombreuses nouvelles commandes primitives qui permettent de contrôler les nouvelles fonctionnalités. ### LuaTeX : dérivé de pdfTeX mais n’utilise pas le code de pdfTeX Par souci d’exactitude, il est important de noter que, bien que nous ayons décrit LuaTeX comme dérivé de pdfTeX, LuaTeX n’utilise pas directement le code original du programme pdfTeX. L’un des développeurs de LuaTeX (Taco Hoekwater) a entrepris la tâche véritablement *herculéenne* de réécrire le moteur TeX de base de LuaTeX en code C propre et moderne (CWEB). #### Note historique En partie à cause de l’ancienneté du code source TeX original de Knuth — dont dérivent ses descendants modernes — le modifier pour adapter ou créer de nouveaux moteurs de composition fondés sur TeX est un processus complexe et tortueux. Une partie de ce processus exige la conversion du code Pascal en code C — ce qui n’est pas sans [un certain degré de complexité](http://www.readytext.co.uk/?p=2529). Le code C résultant, généré automatiquement par la machine, est extraordinairement verbeux et très difficile à lire ou à comprendre. Clairement, le fait que le code de LuaTeX soit entièrement réécrit contourne tout le processus de conversion de Pascal vers C. ## Les briques de LuaTeX Dans l’introduction, nous avons fait référence à LuaTeX comme à une « boîte à outils » et l’avons décrit comme un « système de construction et d’ingénierie de documents ». Nous avons vu que, dans l’annonce de LuaTeX 1.0, ses développeurs déclaraient : > « Notre principal objectif est de fournir une variante de TeX qui autorise les extensions utilisateur sans qu’il soit nécessaire d’adapter le fonctionnement interne. » Il est maintenant temps de rassembler ces fils et ces idées pour nous concentrer sur les détails de ce que tout cela *veut réellement dire* dans la pratique. ### Le puzzle LuaTeX Si vous regardiez « sous le capot », vous verriez que le logiciel LuaTeX, c’est-à-dire le programme exécutable lui-même, est constitué d’une collection de composants logiciels combinés ensemble pour fournir l’ensemble des fonctionnalités de LuaTeX. Bien sûr, ce n’est rien de nouveau et la plupart des logiciels sont construits de cette manière. Cependant, ce qui distingue LuaTeX des autres moteurs TeX, c’est que ces composants sont combinés de telle sorte que les utilisateurs disposent d’un accès bien plus large à de nombreux aspects des fonctionnalités internes de TeX : algorithmes de composition de TeX, processus décisionnels, données et structures de données. Cette ouverture des entrailles de TeX permet aux utilisateurs de construire de nouvelles solutions de composition sans avoir à modifier le moteur TeX lui-même. ### Le Lua dans LuaTeX : une clé de la « boîte noire » Lua est un langage de script très puissant, mais facile à apprendre, qui [est originaire du Brésil](https://www.lua.org/about.html)—il a été créé en 1993 et continue d’être activement développé. L’un des points forts de Lua est son utilisation comme langage de programmation permettant de « faire communiquer » des composants logiciels disparates, vous autorisant à les utiliser au moyen d’un langage de script simple mais polyvalent. Lua joue un rôle central dans l’ouverture du fonctionnement interne du moteur TeX LuaTeX, mais pour mieux comprendre comment cela est réalisé, il vaut la peine de faire un léger détour pour aborder très brièvement deux concepts de programmation : * interface de programmation applicative (API) ; * liaison de langage. N’hésitez pas à sauter cette section si ces concepts vous sont familiers. Aucun des deux sujets ne sera traité en détail — nous n’avons pas pour objectif une rigueur technique stricte, mais plutôt de fournir juste suffisamment de contexte pour connaître ces concepts : leur signification et leur pertinence pour LuaTeX. ### Interface de programmation applicative (API) Imaginez que vous êtes un programmeur ayant écrit du code que des utilisateurs (d’autres programmeurs) pourraient trouver utile, mais votre code est complexe et vous ne voulez pas que les utilisateurs de votre code aient à se soucier de ces détails de bas niveau. Notez que ces programmeurs/développeurs travaillent dans le même langage de programmation que celui que vous avez utilisé pour écrire votre code. En outre, supposons que vous envisagiez de réécrire certaines parties de votre code — par exemple pour le rendre plus rapide, consommer moins de mémoire, etc. Les utilisateurs actuels de votre code ne devraient pas avoir à s’en inquiéter : toute modification que vous prévoyez d’apporter ne devrait pas casser leurs programmes. Alors, quelle est la solution ? La réponse tient dans ce qu’on appelle une API : une *interface de programmation applicative*. Plutôt que d’obliger les utilisateurs (d’autres programmeurs) à accéder aux détails de bas niveau de votre code — qui pourraient changer — vous fournissez un ensemble spécifique de *fonctions* que d’autres programmeurs peuvent utiliser. Ces fonctions constituent une *interface* avec votre code, grâce à laquelle d’autres développeurs peuvent créer des *applications* sans avoir besoin d’une connaissance intime du fonctionnement interne de votre programme. D’une certaine manière, on peut voir cela comme une couche supplémentaire qui entoure votre code et « isole » les utilisateurs des détails désordonnés de bas niveau. À condition de ne pas modifier ces fonctions (l’interface), vous êtes libre de modifier et de mettre à jour les détails de plus bas niveau de votre logiciel sans affecter (casser) le travail de ceux qui s’appuient sur votre code pour construire leurs applications : d’où le terme interface de programmation applicative. #### API : une analogie avec un package LaTeX Lorsque vous utilisez des commandes fournies par un package LaTeX, vous pouvez considérer les commandes de ce package comme une forme d’API. En tant qu’utilisateur, vous ne vous souciez pas nécessairement de la magie TeX et LaTeX qui se cache derrière ces commandes (c’est-à-dire dans le code du package) : tout ce que vous voulez, c’est faire usage des fonctionnalités qu’elles fournissent. ### Liaison de langage Nous avons vu que les programmeurs qui écrivent/publient un ensemble de code utile (appelé une *bibliothèque*) peuvent fournir ce qu’on appelle une interface de programmation applicative (un ensemble de fonctions) grâce à laquelle d’autres programmeurs, utilisant le *même* langage de programmation, peuvent utiliser cette bibliothèque (collection de code). C’est très bien lorsque les deux parties (le développeur de la bibliothèque et ses utilisateurs) utilisent le *même* langage de programmation, mais que se passe-t-il si des programmeurs utilisant un *langage de programmation différent* veulent eux aussi utiliser cette bibliothèque ? Par exemple, vous pourriez écrire des scripts en Lua mais vouloir utiliser une bibliothèque écrite dans, par exemple, des langages de programmation tels que C/C++. D’une manière ou d’une autre, les deux langages de programmation différents (Lua et C/C++) doivent pouvoir « communiquer » entre eux. Une solution à ce problème est ce qu’on appelle une [liaison de langage](https://en.wikipedia.org/wiki/Language_binding). L’examen des détails techniques de la liaison de langage dépasse le cadre du présent article, nous allons donc en donner un résumé concis des principes généraux. En substance, en ajoutant à la bibliothèque d’origine une couche supplémentaire de code appropriée, celle-ci peut « communiquer » avec un autre langage de programmation (tel que Lua) : cette couche de code est appelée une *liaison*. Elle permet aux deux langages d’interopérer via une API à l’aide de laquelle les programmeurs du second langage (comme Lua) peuvent accéder aux fonctionnalités/services fournis par la bibliothèque. ![Schéma illustrant le concept de liaison de langage.](/files/0ad8cbd091e02c21046dffe0fb977f03d410d96e) **Figure 1**: Schéma illustrant le concept de liaison de langage : permettre à un programme écrit en Lua d’utiliser une bibliothèque externe écrite dans un autre langage de programmation. C’est grâce à l’utilisation de liaisons Lua que les composants internes de LuaTeX, et donc une grande partie des fonctionnalités internes de composition de LuaTeX, deviennent accessibles aux utilisateurs pour développer des solutions à des problèmes complexes de composition. ## LuaTeX : deux options de programmation — TeX et Lua En substance, LuaTeX est un moteur TeX qui prend en charge deux langages de programmation : le langage traditionnel fondé sur TeX et le langage de script Lua. Bien sûr, vous pouvez utiliser les deux langages dans le même document TeX ou, si vous préférez, continuer à composer uniquement via la voie TeX : par exemple au moyen du package de macros LaTeX (LuaLaTeX). TeX (ou LaTeX) n’est pas un langage de programmation facile à utiliser ou à apprendre, et relativement peu de personnes ont véritablement maîtrisé les nombreuses idiosyncrasies de TeX — les concepts de TeX de [jetons](https://www.overleaf.com/blog/522-what-is-a-tex-token) et d’expansion sont assez étrangers aux attentes et aux expériences de la plupart des gens en matière de langage de programmation. L’ajout de Lua ouvre la possibilité d’utiliser la composition fondée sur TeX via un langage de programmation beaucoup plus accessible et conventionnel — comme indiqué au début de cet article, en utilisant l’API Lua, vous pouvez réaliser [une composition sophistiquée avec pratiquement aucun code TeX](http://wiki.luatex.org/index.php/TeX_without_TeX). ### LuaTeX ajoute de nombreuses nouvelles primitives Chaque moteur TeX fournit des centaines de commandes dites primitives : les briques fondamentales du langage fondé sur TeX pris en charge par chaque moteur de composition individuel. La version originale de TeX publiée par Donald Knuth fournissait environ 320 commandes, mais les moteurs TeX plus récents (pdfTeX, XeTeX et LuaTeX) ont chacun ajouté de nombreuses nouvelles primitives afin de donner aux utilisateurs accès aux fonctionnalités et capacités supplémentaires de chaque moteur. Le grand nombre de nouvelles primitives de LuaTeX est documenté dans son [manuel de référence](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co). Parmi les nombreuses nouvelles primitives introduites par LuaTeX figure celle appelée `\directlua{...}` qui est la porte d’entrée vers l’utilisation du code Lua : l’accès aux entrailles du moteur LuaTeX pour construire des outils et des solutions de composition sophistiqués. ### \directlua{...} : la porte d’entrée vers la programmation Lua Comme nous l’avons vu, le langage de script Lua peut être considéré comme fournissant une « couche » à travers laquelle il est possible d’accéder au moteur de composition fondé sur TeX de LuaTeX et aux fonctionnalités fournies par de nombreux composants à partir desquels LuaTeX est construit. Le langage Lua est également le mécanisme qui permet l’extensibilité de LuaTeX — grâce à la capacité de Lua à charger des bibliothèques logicielles externes spécialisées. Collectivement, l’interface Lua (ensemble de fonctions fondées sur Lua) fournie par LuaTeX est appelée son *API Lua*: c’est la « liaison de communication » entre le moteur/les composants internes de LuaTeX et le document de l’utilisateur. ### Un exemple simple de \directlua{...} Les *extrêmement simple* exemple ne fait même pas encore le tour de la question, loin de là. Cependant, il sert à démontrer l’idée de base de l’interaction entre la « manière TeX » et la « manière Lua » d’accéder aux paramètres de TeX. Notez que : * `\hsize` est une primitive TeX (commande) qui définit la valeur d’un paramètre interne déterminant la largeur des lignes composées — par exemple, vous la définissez généralement à une valeur appropriée dans un `\vbox{...}`. `\hsize` n’est qu’un *de nombreuses* des paramètres TeX auxquels vous pouvez accéder et/ou que vous pouvez modifier par du code Lua. * L’accès aux paramètres TeX n’est qu’un *minuscule* aspect de l’API Lua de LuaTeX : il y a bien plus encore ! ```latex \documentclass{article} \begin{document} \let\\\relax % redéfinir la signification de \\ pour éviter les problèmes d’expansion Voici la valeur actuelle de {\ttfamily\string\hsize} (via \LaTeX) : \the\hsize\par \directlua{ % Obtenir la valeur actuelle de \hsize à l’aide de l’API Lua local hs=tex.hsize % Utiliser une fonction de l’API Lua pour afficher du % code LaTeX et la valeur de \hsize tex.print("Voici la valeur de {\\ttfamily\\string\\hsize} rapportée depuis le code Lua (en points scalés) : ") tex.print(hs.."\\par") % Définir une nouvelle valeur pour \hsize à l’aide de l’API Lua tex.hsize="400pt" % ou utilisez tex.hsize=400*65536 (en points scalés) }% % Une fois \directlua terminé, demander à \LaTeX % de nous indiquer la nouvelle valeur de \hsize Voici la valeur de {\ttfamily\string\hsize} rapportée par \LaTeX{} après la fin de {\tt\string\directlua} : \the\hsize\par \end{document} ``` Voici une image montrant le résultat de la composition LaTeX par LuaTeX (ci-dessus) : ![Résultats de l’exécution de LuaTeX](/files/b820e56474b94706024c16e8a1e290a23728d80c) Notez que la « ruse » TeX de `\let\\\relax` vise à éviter les problèmes causés par l’« expansion » du code Lua par LuaTeX : un sujet que nous notons brièvement ci-dessous. ### Utilisation du code Lua Il existe deux options principales pour utiliser du code Lua dans vos documents TeX/LaTeX : 1. **Intégré**: écrire du code Lua directement dans votre `.tex` document (comme dans l’exemple ci-dessus) ; 2. **Externe**: stocker le code Lua dans des `.lua` fichiers de code externes et utiliser les fonctionnalités de Lua pour les charger et les exécuter. L’option (1) est la plus adaptée à des fragments de code Lua courts. L’option (2) est utilisée pour des programmes plus volumineux ou des bibliothèques de code Lua. Elle présente un avantage distinct : elle vous permet d’éviter les problèmes délicats liés aux soi-disant `\catcode` valeurs (ce qui peut être « assez frustrant »). La raison de ces `\catcode` problèmes est l’« expansion » du code Lua avant son injection dans l’interpréteur Lua intégré de LuaTeX. Cette expansion peut être délicate à comprendre, nous l’explorerons donc plus en détail dans un article ultérieur. Bien sûr, il existe des packages LaTeX pour aider à utiliser du code Lua dans vos fichiers .tex — par exemple, vous pouvez utiliser le [package luacode](https://ctan.org/pkg/luacode?lang=en). ## Résumé et introduction de la partie 2 de cet article Les composants logiciels à partir desquels LuaTeX est construit, ainsi que le langage de script Lua intégré, offrent une puissante combinaison pour élaborer des solutions capables de résoudre un large éventail de problèmes de composition complexes — et d’ingénier des flux de travail de production de documents pouvant bénéficier d’une étroite intégration avec un moteur de composition basé sur TeX. Dans [La partie 2 de cet article](/latex/fr/articles-approfondis/09-an-introduction-to-luatex-part-2-understanding-directlua.md) nous examinons en profondeur la commande la plus puissante fournie par LuaTeX : `\directlua`. D’ici là, bon LuaTeXage ! ## Remerciements L’auteur est extrêmement reconnaissant envers [Luigi Scarso](https://twitter.com/luigi_scarso), l’un des développeurs de LuaTeX, d’avoir pris le temps de lire un brouillon de cet article et d’avoir formulé un certain nombre de commentaires et de suggestions très utiles. Toute erreur factuelle ou omission restante relève, bien sûr, de l’auteur. De plus, je voudrais remercier [Patrick Gundlach](https://twitter.com/patrickgundlach), développeur de [speedata publisher](https://speedata.github.io/publisher/), pour le temps qu’il a consacré à répondre à mes questions. --- # 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/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.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.