Le mpg-blog

LuaTeX 0.60.2 est sorti officiellement il y a quelques jours. C’est très probablement la version qui sera dans TeX Live 2010. Les changements, pour cette version dans la branche « stable » 0.60.x, sont bien sûr des corrections de bogues. Voici une traduction approximative de la liste des modifications, suivie de quelques commentaires sur des fonctionnalités évoquées pour se cultiver au passage.## Liste des changements

• Plusieurs problèmes de portabilité réglés, en particulier pour les compilateurs autres que gcc.
• Mise à jour de SyncTeX par Jérôme Laurens.
• Correction du bogue 406 : \pdfliteral gênait la césure.
• Correction d’un problème de surimpression en PDF (lié à \pdfliteral).
• Intégration d’un patch d’Akira Kakuto assurant que seules les commandes qui sont dans le PATH sont exécutées sous Windows en mode \write18 restreint.
• Correction d’un débordement de tampon dans luafontloader.
• Correction de problèmes de dépendance de la plate-forme pour les formats générés.
• Correction de coquilles dans la manuel.
• Correction d’un problème avec la glue (ressort) nulle écrasée par le code de référence des attributs.
• Documentation du caractère déprécié et cassé du traitement des otp.

Exécution restreinte de commandes

Une des nouveautés de TeX Live 2010 (précédemment prévue pour TeX Live 2009 mais reportée suite à plusieurs problèmes) est d’ajouter un nouveau niveau d’autorisation concernant l’exécution de commandes depuis TeX (souvent appelé \write18, du nom de la commande TeX le permettant) ; jusqu’ici les deux niveaux possibles étaient « tout est permis » ou « rien n’est permis ». Le nouveau mode, « restreint », a pour but d’autoriser seulement l’exécution de commandes (réputées inoffensives) appartenant à une liste fixée.

Cette fonctionnalité pose des problèmes délicats, par exemple le fait que, sous Windows, les commandes sont toujours recherchées en priorité dans le répertoire courant (quel que soit le réglage du PATH). Sachant que TeX peut écrire des fichiers arbitraires dans le répertoire courant, on imagine sans peine les possibilités d’attaque que cela ouvre. Plusieurs mesures sont prises pour éviter ces problèmes ; le patch mentionné ci-dessus n’est probablement pas propre à LuaTeX mais appartient sans doute à une série concernant d’autres exécutables de TeX Live.

Formats et boutisme

Les jeux de macros comme LaTeX, plutôt que d’être lus et interprétés par *TeX (lire : TeX ou pdfTeX ou XeTeX ou LuaTeX ou …) à chaque démarrage, sont traités une bonne fois pour tout et stockés sur le disque sous forme de fichiers .fmt : les formats. Ces fichiers formats constituent une image de la mémoire de *TeX, et sont donc très rapides à charger au démarrage.

Cependant, l’état précis de la mémoire de *TeX dépend de paramètres comme le boutisme du processeur (les octets de poids fort sont-ils au début où à la fin). Des précautions particulières sont prises à la création du fichier format et à son chargement pour inverser si nécessaire l’ordre des octets, de sorte que le fichier format soit indépendant du boutisme ambiant, ce qui facilite grandement la gestion d’installations TeX partagées entre des machines de boutisme différent.

Cette question concerne toutes les variantes de TeX et est en général réglée depuis longtemps. Cependant, LuaTeX pose des problèmes nouveaux en ce domaine, par exemple à cause de la possibilité de stocker du code Lua dans le format : par défaut le bytecode généré par Lua n’est pas indépendant de la plateforme, et l’équipe LuaTeX a du l’adapter pour obtenir la propriété voulue. Un problème de ce type vient donc encore d’être corrigé.

Héritage d’Omega

LuaTeX admet plusieurs parents directs, dont le plus connu est pdfTeX, mais un autre parent non moins important est Aleph (le successeur d’Omega), qui permettait déjà une bonne gestion d’Unicode, et proposait une gestion des écritures multi-directionnelles qui a été reprise par LuaTeX (de préférence à celle d’e-TeX, présente aussi dans pdfTeX).

En première approximation et à l’origine, LuaTeX formait un sur-ensemble d’Aleph (et d’Omega) et incluait ainsi tous les mécanismes développés par Omega. L’un de ces mécanismes, OTP (Omega Translation Process) avait pour but de permettre une conversion automatique entre codages de caractères, et plus généralement des manipulations sur les flux de caractères entrant et sortant d’Omega. LuaTeX propose de meilleures solutions à ces problèmes, avec ses différents callback Lua.

Le traitement des OTP est désormais officiellement déprécié, après avoir été cassé depuis quelque temps déjà. Ce cas me semble représentatif de plusieurs fonctionnalités héritées d’Omega, parmi lesquelles aucun ménage systématique n’a encore été fait mais qui sont peu ou pas testées du fait de l’existence de meilleurs solutions dans LuaTeX, et sont donc souvent cassées (parfois, elles l’étaient déjà dans Omega, mais c’est une autre histoire) et appelées à progressivement disparaître.