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.

Des exécutables seront bientôt disponibles sur la page téléchargements du projet, et j’ai précédemment expliqué comment installer une version récente de LuaTeX sur TeX Live, pour ceux qui veulent l’essayer sans attendre.

Nouvelles fonctionnalités

• os.name prend maintenant en compte CYGWIN (par Élie Roux).
• La gestion interne des spécifications de direction est plus rapide maintenant.
• Chaque nœud de glyphe a maintenant trois champs virtuels en lecture seule : width, height, et depth (les valeurs sont en sp (points d’échelle) bien sûr).
• Il y a de nouvelles fonctions node.protrusion_skipable() et tex.badness() (utiles pour le découpage des paragraphes en Lua).
• Également nouveau : tex.linebreak(). Voir le manuel pour les détails.
• Toutes les erreurs en Lua indiquent maintenant le fichier et le numéro de ligne pour aider à déboguer.
• Import de Metapost 1.211.
• pdf.pdfcatalog sera bientôt remplacé par le nouveau pdf.catalog ; pdf.pdfinfo sera bientôt remplacé par le nouveau pdf.info ; pdf.pdfnames sera bientôt remplacé par le nouveau pdf.names ; pdf.pdftrailer sera bientôt remplacé par le nouveau pdf.trailer.
• pdf.pdfmapfile et pdf.pdfmapline sont remplacés pas les nouvelles fonctions pdf.mapfile() et pdf.mapline() (une fonction convient mieux comme interface pour ces paramètres vu qu’il ne retournent jamais rien).
• Nouvelles variables Lua en lecture et écriture : pdf.pagesattributes, pdf.pageresources, pdf.pagesresources.
• getluatexsvnversion.sh détecte maintenant correctement git-svn et arrive encore à trouver un numéro de révision SVN valide (de Patrick Gundlacj).
• Plusieurs fichiers sources ont été convertis en CWEB.

Corrections de bogues

• GNU libtool est maintenant utilisé pour résoudre les problèmes techniques variés liés au chargement dynamique de modules Lua.
• La détection des erreurs dans scan_interger_part était incorrecte car OK_so_far n’était pas initialisée (remarqué par Javier Mugica).
• Synctex était cassé dans 0.51 et 0.52.
• \lastlinefit était cassé depuis… euh, à peu près toujours.
• La lecture des fichiers binaires de taille nulle était cassée.
• Détection des réglures non initialisées (pour les nœuds de réglures créés de travers depuis Lua).
• pdfimmediatobj('streamfile') était cassé sur les plate-formes 64 bits.
• tex.linebreak ne prenait pas les valeurs de ressort droit et gauche données, mais utilisait en fait les valeurs courantes coté TeX (bug #356).
• La commande make de build.sh est maintenant passée à configure pour résoudre les problèmes où GNU make n’était pas trouvé alors qu’il était effectivement installé.
• dofile(<nil>) et loadfile(<nil>) en batchmode provoquent maintenant une erreur et continuent plutôt que d’attendre inutilement une entrée de l’utilisateur.
• Annulé le commit numéro 3417 (l’expérience avec buildpage) car il provoque des problèmes quand des items sont en attente au moment du saut de page.
• loaders[4] est écrasé en mode --safer; require() se comporte de façon plus semblable au Lua 5.1 normal ; meilleurs messages d’erreur (d’après un e-mail et des patchs de Manuel Pégourié-Gonnard).
• Test supplémentaire au chargement GDEF dans luafontloader, basé sur un crash causé par la fonte AkaashNormal.ttf de Linux.

Le comment

Vu que l’installation des binaires se fait forcément dans l’arborescence principale de TeX Live, toutes les explications qui suivent supposent que vous installez les fichiers d’initialisation dans TEXMFLOCAL, car je ne vois pas de raison d’utiliser plutôt TEXMFHOME. Pour connaître la valeur de TEXMFLOCAL, utilisez la commande suivante.

kpsewhich --var-value TEXMFLOCAL

Par ailleurs, je suppose que vous avez les privilèges suffisants pour effectuer toutes les opérations décrites. Il est conseillé d’installer TeX Live en tant que simple utilisateur (surtout si vous comptez la bidouiller beaucoup, comme c’est l’objet de ces billets), mais si vous ne l’avez pas fait, n’hésitez pas à utiliser sudo ou su sous Unix, ou « ouvrir une ligne de commande en tant qu’administrateur » sous Windows au besoin.

Dans TEXMFLOCAL/tex/generic/config, créez un fichier nommé luatexiniconfig.tex ayant le contenu suivant.

\begingroup
\catcode `\{=1
\catcode `\}=2
\expandafter\ifx\csname luatexversion\endcsname\relax
  \let\luatexversion\undefined
  \directlua{tex.enableprimitives('', tex.extraprimitives())}
\fi
\endgroup

Ensuite, trouvez l’arborescence TEXMFDIST (utilisez kpsewhich --var-value au besoin), et copiez de cette arborescence vers TEXMFLOCAL les fichiers suivants.

tex/plain/config/luatex.ini
tex/plain/config/pdfluatex.ini
tex/latex/latexconfig/lualatex.ini
tex/latex/latexconfig/pdflualatex.ini

Éditez ensuite la copie présente dans TEXMFLOCAL de chacun de ces fichiers, pour ajouter au tout début (juste après les commentaires initiaux) la ligne

\input luatexiniconfig

Il faut maintenant mettre à jour la base de données des fichiers de TeX. Vu que tous les fichiers créés sont dans TEXMFLOCAL, il suffit de se placer dans ce répertoire et de taper

mktexlsr .

Tout ceci est à effectuer une fois avant d’installer une version supérieure ou égale à 0.39.0 de LuaTeX, par la méthode donnée dans le billet précédent.

Le pourquoi du comment

Sans la manipulation décrite ci-dessus, vous aurez une erreur au moment de re-générer les formats (l’étape fmtutil-sys). En effet, les fichiers d’initialisation des formats supposent qu’un certain nombre de primitives fournies par e-TeX ou pdfTeX existent, ce qui est bien naturel vu qu’il sont destinés à un moteur précis.

Or, depuis la version 0.39.0, LuaTeX (en mode INI, c’est-à-dire sans format pré-chargé) démarre avec exactement les même primitives que TeX82, sauf \directlua en plus. Si on veut accéder aux nouvelles primitives, il faut explicitement demander leur activation avec la fonction Lua tex.enableprimitives(). Ceci présente deux avantages :

• si dans un futur distant on veut réellement remplacer pdfTeX par LuaTeX, on peut (en utilisant le deuxième argument de tex.enableprimitives()) n’activer que les primitives pdfTeX dans ce mode-là.
• en activant les primitives, on peut si on veut (premier argument de tex.enableprimitives()) leur ajouter un préfixe (par exemple \LuaTeXprimitive au lieu de \primitive) pour éviter les conflits de noms avec des macros déjà utilisés dans différents paquets.

Pour plus de détails, voir les parties 2.1 et 4.1.14 d’un version récente du manuel LuaTeX.

Avertissements préliminaires

• Pour les versions de LuaTeX supérieures ou égales à 0.39.0, une étape supplémentaire est requise (à effectuer une seule fois), décrite dans le billet suivant.
• Tout ceci concerne une version « nature » de TeX Live. Si vous utilisez les paquets TeX Live de Debian, des paquets pour LuaTeX existent (dans sid et testing) et fournissent des version relativement récentes de LuaTeX.

Le how-to et certaines explications

Pour une fois, c’est un peu plus qu’un « comment j’ai fait », puisqu’au moins une autre personne a testé. La première chose à faire est bien sûr de récupérer le binaire d’une version récente de LuaTeX. On en trouve pour Linux et Windows sur la page Gforge de LuaTeX, et pour d’autres plateformes, mais avec potentiellement un peu plus de délai, sur la page téléchagement de LuaTeX. (Attention, sur la page Gforge, l’ordre est trompeur et les version les plus récentes sont en bas de la page).

Il faut maintenant intégrer ce binaire à votre TeX Live. Si vous avez accepté les réglages par défaut lors de l’installation, vos binaires « normaux » de TeX Live sont sous

/usr/local/texlive/2008/bin/<arch>-linux
C:\Program Files\texlive\2008\bin\win32

selon que vous êtes sous Linux ou Windows. Nous allons placer les nouveaux binaires dans un répertoire parallèle en remplaçant la dernière composante du chemin ci-dessus par i386-linux-latest ou win32-latest par exemple. (Adaptez au besoin.)

Cet emplacement n’est pas choisi au hasard : il y a dans TeX Live tout un tas de fichiers que TeX et ses variantes on besoin de localiser. Comme il est a priori possible d’installer TeX Live n’importe où sur le disque, il faut que les programmes aient un moyen de s’y retrouver. Le moyen retenu (sous TeX Live) est simple : le programme regarde où il se trouve sur le disque, et en déduit où se trouvent les autres fichiers. Il faut donc bien prendre garde de ne pas le placer n’importe où.

Il faut ensuite ajouter ce répertoire à son PATH, avant le répertoire par défaut de TeX Live. Je reviendrai là-dessus dans la partie spécifique au système d’exploitation.

Il faut ensuite re-générer les formats. Si cette dernière phrase vous paraît incongrue, un mot d’explication. Quand on utilise la commande latex, il y a en fait (essentiellement) deux fichiers en jeu : le programme pdftex (ou pdftex.exe) et le « format » latex.fmt. Ce dernier comprend des définitions (comme par exemple celle de \documentclass) sous une forme « pré-compilée » et très rapide à charger. Les fichiers .fmt utilisent un format binaire qui ne peut pas être partagé entre différentes versions du programme sous-jacent. Je répète donc : il faut ensuite re-générer les formats (en espérant que ça passe mieux cette fois).

C’est très simple, en ligne de commande on fait

fmtutil-sys --byfmt luatex
fmtutil-sys --byfmt pdfluatex
fmtutil-sys --byfmt lualatex
fmtutil-sys --byfmt pdflualatex

(Muni des privilèges suffisants pour écrire dans les répertoire de TeX Live. Pour un utilisateur d’Unix, ça peut impliquer l’usage de sudo où su.)

Bien, on a fait la moitié du travail pour pouvoir lancer une commande comme pdflualatex : créer un fichier pdflualatex.fmt viable. L’autre moitié est de faire comprendre à notre système d’exploitation que quand on lance la commande pdflualatex, c’est en fait notre nouveau programme luatex (ou luatex.exe) qu’il faut utiliser. Cette partie dépend du système d’exploitation.

Sous Linux, Mac OS, ou autre variante d’Unix

C’est très simple, il suffit, dans notre répertoire ii386-linux-latest (ou autre) nouvellement créé, et qui ne contient que luatex pour le moment, de créer des liens symboliques vers celui-ci.

for l in pdfluatex lualatex pdflualatex texlua texluac; do
ln -s luatex $l; done

Hop, c’est tout. Vous avez remarqué texlua et texluac ? C’est pour utiliser LuaTeX comme un simple interpréteur Lua (resp. un compilateur de Lua en bytecode). Utile si vous voulez pratiquer tranquillement Lua, ou écrire des scripts portable à utiliser dans le contexte de TeX (par exemple, texdoc est un script interprété par texlua depuis TeX Live 2008, ce qui lui permet de fonctionner aussi sur windows, contrairement à la précédente implémentation sous forme de script shell).

Maintenant, ça vous dérange peut-être d’avoir dans votre PATH deux répertoires rien que pour TeX Live. Moi ça me dérange en tout cas. Pas de problème, on fait (par exemple)

for f in ../x86_64-linux/*; do ln -s $f; done

pour créer des liens symboliques de notre nouveau répertoire vers les fichiers de l’ancien, et on peut ainsi ne garder que le nouveau dans le PATH.

Attention, si lors de l’installation vous aviez choisi l’option « ajouter des liens symboliques dans les répertoires standard », oubliez tout ce que j’ai dit précédemment sur le PATH. Placez simplement des liens symboliques vers .../bin/<arch>-latest en amont de /usr/local/bin dans votre PATH. En principe, ~/bin fait très bien l’affaire pour ça (enfin, peut-être pas sous OS X). Il vous faut bien sûr créer des liens symboliques avec tous les noms voulus. Par contre, il faut continuer à placer le binaire à l’endroit indiqué (et pas par exemple directement dans votre ~/bin, car c’est ce qui compte pour qu’il trouve ensuite les fichiers de TeX Live.

Sous windows

Ici, on n’a pas de liens symboliques (quoi que… sous NTFS je crois que si, mais je ne sais pas faire). Qu’à cela ne tienne, on va faire des copies. On crée donc dans notre nouveau répertoire win32-latest des copies de luatex.exe nommées pdfluatex.exe, lualatex.exe, pdflualatex.exe, texlua.exe et texluac.exe (voir ci-dessus pour l’utilité de ces deux derniers).

Si vous souhaitez n’avoir qu’un seule répertoire TeX Live dans votre PATH, le plus simple est de commencer par recopier le précédent sous le nouveau nom, et ensuite seulement de remplacer les fichiers dans la copie.

Dernières remarques

LuaTeX est vraiment en bêta. Ne l’utilisez qu’à des fins de test ou de développement. Par ailleurs, une bonne raison pour en installer une version plus récente que 0.25.4 est que cette dernière souffre d’un problème important. Elle ne peut pas charger les fontes qui sont utilisée par défaut par LaTeX avec usepackage[T1]{fontenc}. (Pour l’anecdote, ce n’est pas à proprement parler un bug de LuaTeX : c’est une anomalie dans les fichiers .tfm de ces fontes, non détectée par les variantes de TeX usuel. Dans un sens, LuaTeX avait « raison » de ne pas les accepter, mais les version récentes préfèrent avoir tort et fonctionner…)

Au passage, si vous voulez tester pdflualatex, attention, suite à des progrès importants réalisé par LuaTeX (par rapport à pdfTeX) en matière d’encodages d’entrées et de fontes, inputenc et fontenc ne sont pas actuellement compatibles avec LuaTeX. Il suffit de supprimer inputenc et d’encoder son fichier en utf-8 pour régler le premier point. Pour le deuxième, on peut quand même utiliser fontenc avec T1 en attendant, mais on aura des problèmes sur certains caractères (tout ceux, heureusement rares, qui ne sont pas à la même position dans latin1 et dans T1).

D’abord, quelques rappels historiques. TeX était sans doute le mieux qu’on puisse faire à l’époque où il a été créé, et peut-être encore 10 ans après. Aujourd’hui, il est vieux et porte les traces de l’époque de sa jeunesse : à ce moment, ni pdf, ni unicode, ni opentype n’existaient : en fait, postscript non plus, latin1 non plus, et sans doute aucun format vectoriel de police. Sur ces points, le retard est en train d’être rattrapé (voire de l’avance prise) par XeTeX, et une partie de LuaTeX.

Il est sans doute intéressant de noter que Microsoft a produit avec Word 2007 une police mathématique (Cambria Math) au format OpenType avec toutes les informations métriques voulues pour composer des maths correctement. Leurs algo de composition mathématique sont ouvertement calqués sur ceux de TeX et produisent un résultat de qualité comparable (pour les maths, le texte est encore largement à la traîne). Pour l’instant, ni XeTeX ni LuaTeX ne gèrent l’OpenType mathématique (mais ça ne va pas tarder à changer).

C’est à mon avis significatif sur le fait que TeX avait à une époque plusieurs longueurs d’avance, puisqu’on le copie presque 30 ans après. Par contre, en le copiant, on va un peu plus loin : il s’agit donc de ne pas se reposer sur ses lauriers si TeX doit garder un rôle de leader. Des progrès importants sont en cours dans ce sens avec XeTeX et LuaTeX.

Un autre point où TeX porte un peu la trace de son âge, c’est son manque d’intégration au reste du monde en général. On a déjà parlé des grands standards comme Pdf, PostScript, Unicode et OpenType, mais une foule d’autres détails existent, comme le problème des formats d’images et des modes de compilation, légitimement agaçants pour les utilisateurs.

Par ailleurs, on peut envisager et souhaiter des réformes profondes au niveau de l’interface utilisateur et programmeur de TeX, allant jusqu’à la disparition de TeX en tant que langage. En effet, ce dernier présente des particularités incontournables (dans le sens où on ne peut pas les cacher à l’utilisateur), comme le célèbre problème du verbatim dans les arguments de commandes, qui sont profondément ancrées dans la structure du langage.

La moins profonde des réformes qu’on peut envisager est déjà en cours avec le projet LuaTeX : il s’agit d’ouvrir certaines des routines internes de TeX au programmeur. En effet, celui-ci est parfois bloqué par quelques hypothèses codées en dur dans TeX, qui ne correspondent pas à la situation où il se trouve, tant il est vrai que même Knuth ne pouvait anticiper toutes les utilisations qu’on voudrait faire de TeX après le développement fabuleux qu’il a connu.

Pour le moment, il s’agit, à certains points judicieusement choisis du traitement d’un document par TeX, de rendre la main au programmeur. Ceci laisse en place le flot d’exécution normal prévu par TeX. Or celui-ci est parfois très contraignant, par exemple la notion de routine de sortie.

Au final, on aimerait donc dans l’idéal pourvoir complètement désosser TeX, et n’en garder que les parties les plus intéressantes : algorithmes de césure, de construction des paragraphes, de composition mathématique, structures de données particulièrement adaptées (listes, boîtes) éventuellement en les améliorant, mais en étant libre de les agencer comme on veut. C’est un travail particulièrement énorme, vu le caractère très monolithique de TeX tant dans sa conception que dans son implémentation.

On peut alors rêver d’un système en plusieurs couches comme suit : un cœur centré sur des composants de TeX liés entre eux de façon souple. Des back-end produisant un peu ce qu’on veut : Pdf (X)Html, MathML, etc. Un front-end en deux couches : l’une destinée au programmeur, l’autre à l’utilisateur final.

En effet, actuellement les deux disposent d’un langage commun qui ne satisfait réellement personne. Du point de vue des deux, il est trop complexe et parfois difficile à prévoir, et pour le programmeur il manque de la souplesse que savent fournir des langages modernes, sans même parler du concept de séparation lecture/développement/exécution qui est pour beaucoup dans la complexité du langage actuel.

Notons que cette séparation en couches était plus ou moins prévue dès le départ par Knuth avec la notion de format, et est aussi un des points importants du projet LaTeX3. Enfin, avec des efforts, un bonne conception de ces deux couches permettrait peut-être d’éviter que l’utilisateur de retrouve confronté à des messages d’erreurs que seul le programmeur expérimenté peut comprendre à défaut d’apprécier.

Après ce qui peut ressembler à un réquisitoire, quelques réflexions sur la place de TeX dans le paysage actuel. Il est le seul, parmi les outils destinés à produire des documents de bonne qualité typographique, à fonctionner comme un compilateur de documents, et à être réellement programmable. Ceci le rend très difficile à comparer à d’éventuels concurrents.

Ses atouts essentiels, conséquence des précédents, est qu’il peut automatiser de nombreuses tâches comme la gestion de des références au sens large, notes de bas de pages, etc, mais aussi trouver automatiquement l’optimum typographique sous des contraintes données dans de nombreuses circonstances, là où des outils comme Quark Xpress ou Adobe InDesign demandent une gestion et un ajustement manuel. Il peut aussi beaucoup plus facilement d’intégrer dans des flots de traitement automatisé de documents (penser XML, Docbook, texinfo).

Pour conclure, tant par la place à part qu’il occupe dans le paysage de la typographie assistée par ordinateur, l’intérêt constant de ses algorithmes typographiques, les projets existants visant à mieux l’insérer dans le monde informatique moderne, que par goût personnel, je crois fortement à l’avenir d’une forme de TeX.

Mais le monde de TeX a été très conservateur pendant une longue période, choisissant toujours la stabilité au détriment de l’innovation. Il a donc dans un sens du retard à rattraper, et je pense et espère que les évolutions en cours avec XeTeX et plus encore LuaTeX ne sont que le début d’une révolution, qui promet d’être excitante et riche.