Geekographie Maïeulesque

Bug avec polyglossia v1.45 et reledpar

Maïeul — 2020-04-21T06:00:00Z

La version 1.45 de polyglossia a changé certaines commandes utilisées par reledpar. Par conséquent, celui-ci n'était plus capable de gérer correctement le changement de langue entre les deux textes mis en parallèles.

Nous nous sommes aperçu de cela après la sortie de la TeXLive 2020. Par conséquent, les correctifs ne sont pas disponibles dans la TeXLive 2019.

Correctifs à appliquer

Si vous utiliser la TeXLive 2019, ne mettez pas à jour polyglossia, ou revenez à une version antérieure à la 1.45.
Si vous utiliser la TeXLive 2020, mettez à jour reledpar pour avoir la version 2.23.1.

Bidi reledmac's bug solved with bidi 34.8

Maïeul — 2018-10-12T11:02:11Z

Few days ago, I mentionned that bidi 34.4 has broken reledmac. The version 34.8 of bidi solves this issue.

Il y a quelque jours, je signalais que la version 34.4 de bidi cassait le comportement de reledmac. La version 34.8 résoud ce problème.

Bidi 34.4 breaks reledmac

Maïeul — 2018-10-07T18:07:09Z

The last version of bidi package (v34.4) breaks reledmac features. I am currently discuting with bidi maintener in order to find the best way to solve this issue. During this time, please does not update your bidi installation.

La dernière version de bidi (v34.4) casse le fonctionnement de reledmac. Je suis en train de discuter avec le mainteneur du package pour voir comment résoudre ce problème. En attendant, merci de ne pas mettre à jour bidi.

Polyglossia français debugué

Maïeul — 2018-06-13T17:33:11Z

J'avais publié il y a quelques temps deux articles des bugs de polyglossia lorsqu'on utilise le français :

Bien que résolu depuis longtemps sur le dépôt github, ces bugs n'ont été déposés sur le CTAN qu'en avril 2018. La nouvelle version de polyglossia (1.42.5), qui résoud cela, est livrée avec la TeXLive 2018.

\emph cassé avec la nouvelle version de fontspec

Maïeul — 2017-01-24T13:57:05Z

La version 2.5c de fontspec est sorti le 20 janvier. Cependant cette version casse une fonctionnalité importante : la commande \emph ne fonctionne plus.

Le problème est connu, et une nouvelle version, 2.5d, devrait sortir sous peu.

Comment ma bibliographie a saturé la mémoire de (Xe)LaTeX

Maïeul — 2016-10-23T20:03:40Z

Cette semaine, compilant ma thèse pour une nouvelle relecture de la bibliographie, j'ai eu la désagréable surprise d'obtenir un message d'erreur libellé ainsi « TeX capacity exceeded, sorry [main memory size=5000000 ». J'ai passé un certain à trouver la source du bug. Je vous livre ici l'explication, d'une part parce que dans certaines circonstances d'autres que moi pourraient être amenés à obtenir le même bug, et d'autre part parce que l'explication de celui-ci s'avère intéressante pour comprendre les mécanismes sous-jacents à biblatex, à biber et à XeLaTeX.

Résumé du bug

Lançant ma série de compilations avec latexmk, j'obtiens, à la deuxième compilation XeLaTeX, le message suivant :

TeX capacity exceeded, sorry [main memory size=5000000]

D'habitude, ce type de message est provoqué par une boucle infinie, généralement liée à une faute de code. J'étais relativement sceptique sur l'existence d'une telle boucle, puisque je n'avais pas apporté beaucoup de changement de code depuis la dernière compilation complète effectuée un mois en amont.

Recherche de l'origine [1]

J'ai toutefois procédé à une méthode simple, mais généralement efficace pour trouver la source de ce type de bug : commenter la moitié du contenu LaTeX, compiler, voir si le bug se reproduit, si oui commenter la moitié du code restant, sinon inverser et faire un test sur la moitié qu'on n'avait pas testé, et recommencer, et ainsi de suite, jusqu'à cerner la ligne ou le bloc de code qui pose problème. Il s'agit d'une résolution classique par dichotomie, pas nécessairement la plus rapide, mais la plus simple à mettre en œuvre avec LaTeX.

Néanmoins, dans le cas qui m'occupait, une telle recherche s'est révélée infructueuse : le bug ne se produisait que si je compilais l'ensemble de ma thèse, et non pas l'une ou l'autre des moitiés.

Fort heureusement, je savais que j'avais réussi à compiler il y a quelques semaines, et qu'à l'époque j'avais posé un tag git. Grâce à la géniale fonction git bisect, j'ai pu trouver le commit ayant entraîné le bug, en testant par dichotomie l'ensemble de mes commits entre ma dernière compilation réussie et mon tout dernier commit.

Fort heureusement également, ce commit était relativement petit. J'avais remplacé :

\printbibliography[title={Manuscrits},subtype=ms,check=ms_principaux]

par

\begin{refcontext}[sorting=manuscripts]{} \printbibliography[title={Manuscrits},subtype=ms,check=ms_principaux] \end{refcontext}

Ceci permet que ma bibliographie consacrée aux manuscrits soit triée selon un ordre spécifique, d'abord par ville, puis par bibliothèque, par collection et par cote.

Recherche de la cause

La modification effectuée est donc la source du problème, mais pourquoi pose-t-elle problème ?

Fonctionnement interne de la bibliographie avec LaTeX + Biber

Un élément a éveillé ma curiosité : le bug se produisait AVANT même que la compilation n'ait eu le temps d'arriver à la ligne sur la bibliographie, comme je pouvais le constater à travers les messages défilant à l'écran.

Cependant, je touchais à un élément concernant la bibliographie. Or, voici comment fonctionne la bibliographie avec LaTeX + biblatex + Biber :

Lors de la première compilation, LaTeX lit le fichier .tex, repère les citations à l'intérieur, et écrit dans un fichier .bcf les clefs de citations utilisées ainsi que certaines informations relatives au style bibliographique, dont les informations sur le tri de la bibliographie.
Lors de la compilation Biber, ce dernier lit le fichier .bcf et le mettant en relation avec le fichier .bib, il trie et formate la bibliographie sous la forme d'une suite de commande LaTeX, qu'il écrit dans un fichier .bbl
Lors de la seconde compilation, LaTeX lit non seulement le fichier .tex, mais aussi le fichier .bbl, ce qui lui permet d'ajouter les références bibliographiques et de composer la ou les bibliographies finales.

Ceci est résumé dans le schéma ci-dessous.

Comment fonctionne la compilation de bibliographie dans LaTeX

Puisque le bug n'arrive qu'à la seconde compilation LaTeX, et qu'il est lié à la bibliographie, le problème se situe probablement dans ma bibliographie. Problème : le commit qui introduit le bug n'a rien changé au fichier .bib. Le problème se situe donc plus vraisemblablement au moment de la production du fichier .bbl.

Analyse du fichier `.bbl`

J'ai alors constaté que la taille du fichier .bbl doublait approximativement entre la compilation avant mon commit et celle après mon commit, passant à 4 Mo dans le second cas. Grâce à un logiciel d'affichage de différence entre fichiers, je constate aisément l'origine de la modification : après mon commit, les entrées bibliographiques sont présentes deux fois dans mon fichier .bbl : une fois triées selon mon classement par défaut, anonymous+realauthor, l'autre fois triées selon le classement introduit par mon commit : manuscripts.

Ceci est du reste parfaitement logique, le tri bibliographique étant effectué par Biber et non par LaTeX, il est normal de trouver pour deux demandes de tri,deux listes bibliographiques dans le fichier .bbl, chaque liste commençant par \sortlist et finissant par \endsortlist. Le problème est qu'avec 1253 entrées bibliographiques, cela produit un fichier très lourd, qui, par conséquent, remplit considérablement la mémoire de LaTeX, et aboutit donc à mon TeX capacity exceeded, sorry [main memory size=5000000]

Résolution du problème

Une fois la cause trouvée, il reste à voir comment se sortir de la situation. Trois solutions s'offrent à nous.

Première solution : utiliser LuaLaTeX

TeX, et XeTeX, les moteurs derrière LaTeX et XeLaTeX fonctionnent selon un modèle à quantité de mémoire disponible fixe : lorsque la compilation est lancée, une certaine quantité de mémoire seulement est utilisable.

En revanche, LuaTeX, derrière LuaLaTeX, fonctionne selon un modèle, plus récent, d'allocation dynamique de la mémoire : la mémoire vive utilisée est étendue au fur et à mesure des besoins, le système d'exploitation veillant simplement à ce que LuaLaTeX n'empiète pas sur les autres programme en activité [2]. Conséquence : la quantité de mémoire utilisable par LuaLaTeX ne dépend que de mon ordinateur, et on peut espérer que ma bibliographie doublée n'en vienne quand même pas à saturer toute la mémoire vive et virtuelle [3] de mon ordinateur.

Problème : LuaTeX est un moteur différent de XeTeX, avec ses spécificités, et, étant dans la phase terminale de ma thèse, je ne préfère pas effectuer une migration avec toutes les vérifications, parfois tenues, que cela implique.

Deuxième solution : augmenter la mémoire de XeLaTeX

Puisque je souhaite continuer à utiliser XeLaTeX, deux solutions s'offrent à moi : résoudre mon problème de double tri ou augmenter la mémoire de XeLaTeX. La seconde solution, moins écologique, est plus rapide à mettre en œuvre et consiste à augmenter la mémoire utilisable par XeLaTeX [4].

Une simple recherche sur le web m'indique la démarche à suivre, pour une installation TeXLive [5] :

trouver le fichier de configuration de texlive texmf.cnf en saisissant kpsewhich texmf.cnf dans mon terminal ;
dans mon cas, le fichier est /usr/local/texlive/2016/texmf.cnf ;
ouvrant le fichier je lis les lignes suivantes :
```
% This texmf.cnf file should contain only your personal changes from the % original texmf.cnf (for example, as chosen in the installer).
```
Ceci signifie que je peux y mettre tous mes réglages personnels sans risque de perdre les réglages par défaut que je n'aurais pas explicitement modifiés.
j'ajoute donc le réglage sur de mémoire suivant main_memory = 7999999, ayant lu que cela correspond à la quantité maximum gérable par (X^e)TeX.
puis dans mon terminal, saisir sudo fmtutil-sys --all pour relancer la création des scripts XeLaTeX, LaTeX et co, à partir de mes nouveaux réglages.

Pour m'assurer que mes réglages aient bien été pris en compte, je lance la compilation avec XeLaTeX d'un fichier minimum :

\documentclass{article} \begin{document} \end{document}

J'ouvre le fichier .log généré, et je lis peu avant la fin :

Here is how much of TeX's memory you used: 196 strings out of 493589 2014 string characters out of 6143511 53785 words of memory out of 7999999 3697 multiletter control sequences out of 15000+600000 3640 words of font info for 14 fonts, out of 8000000 for 9000 1347 hyphenation exceptions out of 8191 23i,1n,17p,127b,36s stack positions out of 5000i,500n,10000p,200000b,80000s

La ligne « 53785 words of memory out of 7999999 » m'indique donc que ma quantité de « words of memory [6] » est passée à 7999999, ce qui correspond à mon nouveau réglage. Ouf !

En relance ma compilation de thèse, tout se passe bien [7].

Troisième solution : éviter d'avoir deux bibliographies triées

Cependant, dans le cas où ma bibliographie grossirait encore sensiblement (ce que je n'espère pas), et pour le principe, il paraîtrait plus utile d'avoir la bibliographie triée une seule fois dans le fichier .bbl, que ce soit pour les manuscrits ou pour les autres types d'entrées. De toute façon, je filtre les types d'entrées lors de l'affichage final, pour séparer les manuscrits des autres types.

C'est pourquoi, la version 2.7.0 de biblatex-realauthor, que je viens d'envoyer sur le CTAN propose un nouveau schéma de tri, anonymous+realauthor+manuscripts, que je peux passer comme option global de biblatex, ce qui me permet de supprimer l'environnement refcontext que mon commit problématique avait introduit.

En guise de conclusion

Versionner son travail est très utile. Apprenez à le faire si ce n'est pas déjà fait.
Si vous avez des problèmes de TeX capacity exceeded, sorry [main memory size=5000000] après une compilation biber, et qu'une recherche par dichotomie ne donne rien, regardez la taille du fichier .bbl.

[1] En réalité, je suis arrivé moins directement au but, mais je donne ici la méthode que j'aurais du suivre…

[2] Je schématise, très grossièrement, d'autant plus que je ne suis pas du tout spécialiste de ces questions d'allocation de la mémoire

[3] Pour rappel : la mémoire vive, dont le contenu se vide à l'extinction de l'ordinateur, est plus rapide d'accès, mais plus coûteuse que la mémoire morte (disque dur, SSD), qui ne se vide pas à l'extinction de l'ordinateur. Pour faire leur calcul, les logiciels utilisent de la mémoire vive. Cependant, le système d'exploitation leur alloue également une part de mémoire morte pour simuler la mémoire vive, cette part est appelée « mémoire virtuelle ». Cette mémoire virtuelle, bien qu'utilisant un support à long terme, est destinée à n'être utilisée qu'à court terme.

[4] Sur ce point, XeTeX reste calé TeX, lequel a été inventé en 1977, à une époque où la mémoire informatique était une ressource rare.

[5] Pour MikTeX, j'ignore la démarche

[6] Si j'ai bien compris, un »Word of memory« est l'unité minimale de donnée que traite un processeur. Aujourd'hui, la plupart des ordinateurs neufs ont des »words of memory« de 64 bit, mais il y encore quelques années, la norme était de 32 bit. Avec 7 999 999 »words of memory« , je dispose donc de 511 999 936 bits de mémoire, soit environ 511 Mo. Cela étant, comme j'ignore comme XeTeX structure ses données en interne, je n'ai aucune idée de combien d'éléments bibliographiques je pourrai encore ajouter.

[7] J'ai simplement utilisé 4010951 words of memory sur 7999999, soit un peu plus de la moitié

Polyglossia et XeLaTeX 3.14159265-2.6-0.99996 (TeXLive 2016)

Maïeul — 2016-06-12T19:16:43Z

TeXLive 2016 est sortie lundi dernier. Elle inclut une nouvelle version de XeLaTeX qui nécessite quelques adaptations de polyglossia, lesquelles n'ont pas encore été faites. Heureusement, ceci se corrige en quelques lignes

Le problème

XeTeX propose de définir des classes de caractères (par exemple « signes de ponctuations » « espaces » « guillemets »). Ceci permet d'insérer automatiquement des espaces de tailles déterminées entre certains caractères, selon la classe à laquelle ils appartiennent. Par exemple insérer une espace fine avant les caractères de ponctuation double.

Problème : il existe une classe spéciale, celles correspondant à la limite d'un mot, dont le code était 255 dans les anciennes versions de XeTeX, mais qui dans la version distribuée dans TeXLive2016 est devenue 4095.

Résultat : alors que un mot ; un autre mot mettait une espace fine avant le point-virgule, elle met désormais une espace normale.

La solution

Il suffit simplement de patcher la commande french@punctuation. Ajoutez donc les lignes suivantes dans votre préambule, après avoir chargé le français :

\makeatletter
\appto\french@punctuation{% \XeTeXinterchartoks \french@punctguillstart 255 = {\nobreakspace\xpg@nospace}% "« " -> "«~" \XeTeXinterchartoks 255 \french@punctguillend = {\xpg@unskip\nobreakspace}% " »" -> "~»" \XeTeXinterchartoks \french@punctguillstart 4095 = {\nobreakspace\xpg@nospace}% "« " -> "«~" \XeTeXinterchartoks 4095 \french@punctguillend = {\xpg@unskip\nobreakspace}% " »" -> "~»" \XeTeXinterchartoks 4095 \french@punctthin = {\xpg@unskip\nobreak\thinspace}% \XeTeXinterchartoks 4095 \french@punctthick = {\xpg@unskip\nobreakspace}% }
\makeatother

On retrouve le \makeatletter, \makeatother pour manipuler les commandes contenant des @ dans leur nom. Nous ajouter à la fin de la commande \french@punctuation la déclaration des « tokens » (éléments TeX de base) à ajouter entre les caractéres, en utilisant le bon code de classe.

Ceci inclut la correction pour le bug sur les guillemets signalée il y a peu.

Catalague feature of biblatex-manuscripts-philology repaired with biblatex 3.4

Maïeul — 2016-06-06T08:13:20Z

Some months ago, I wrote that biblatex 3.3 broke the catalogue feature of biblatex-manuscripts-philology.

The version 3.4 of biblatex solves this issue. As TeXLive 2016 is just released, you can obtain it quickly.

Bug avec polyglossia 1.42.4

Maïeul — 2016-04-13T14:42:10Z

Décidément, c'est la saison des bugs. La version 1.42.4 de polyglossia, envoyée sur le CTAN le 25 mars, casse les espaces à l'interieur des guillemets français.

Voici comment contourner le problème, en attendant qu'il soit résolu directement dans polyglossia.

Le problème

Soit le les lignes suivantes :

\documentclass{article} \usepackage{polyglossia} \setmainlanguage{french} \setotherlanguage{english} \usepackage[french=guillemets]{csquotes} \begin{document} \enquote{x} \end{document}

Avant la version 1.42.4 de polyglossia, des espaces étaient automatiquement insérées au niveau des guillemets.

Espaces dans les guillemets : bonne typographie

Après cette version, les espaces disparaissent.

Pas d'espaces dans les guillemets : mauvaise typographie

La solution

Le problème a été introduit par un commit visant à résoudre un autre problème.

On pourrait évidemment surcharger le fichier french.ldf modifié par ce commit pour revenir à l'ancien fichier. Toutefois, il n'est en généralement pas conseillé de surcharger un fichier entier : on ne profite pas des évolutions futures.

Cependant il est assez simple de corriger cela. Il suffit de rétablir au sein de la commande \french@punctuation les codes commentés, et ce grâce à la commande \apptocmd qui permet d'ajouter des morceaux de code à la fin d'une commande déjà existante.

Comme la commande \french@punctuation contient des @, et que les commandes que l'on souhaite insérer aussi, il faut entourer notre \apptocmd de \makeatletter…\makeatother.

Cela étant, le seul bout de code à insérer dans le préambule est :

\apptocmd{\french@punctuation}{% \XeTeXinterchartoks \french@punctguillstart 255 = {\nobreakspace\xpg@nospace}% "« " -> "«~" \XeTeXinterchartoks 255 \french@punctguillend = {\xpg@unskip\nobreakspace}% " »" -> "~»" }{}{}

Je ne manquerais pas de vous tenir au courant lorsque la nouvelle version de polyglossia sera sortie, mais il faudra alors passer à la TeXLive 2017, la TeXLive 2016 étant gelée.

Corrigenda : si vous utiliser TeXLive 2016, lisez l'article suivant "Polyglossia et XeLaTeX 3.14159265-2.6-0.99996 (TeXLive 2016)".

Remerciement à Aurélien Berra pour avoir signalé le problème et trouvé la piste de solution.

biblatex 3.3 breaks the catalog feature of biblatex-manucripts-philology

Maïeul — 2016-03-16T15:58:06Z

The version 3.3. of biblatex breaks the catalog feature of biblatex-manucripts-philology which allows to add catalog in the manuscripts description.

I have no idea of the cause, and so the way to solve it. Consequently, if you use biblatex-manucripts-philology, wait before updating biblatex [1].

[1] I have submitted the problem.

Geekographie Maïeulesque

Bug avec polyglossia v1.45 et reledpar

Correctifs à appliquer

Bidi reledmac's bug solved with bidi 34.8

Bidi 34.4 breaks reledmac

Polyglossia français debugué

\emph cassé avec la nouvelle version de fontspec

Comment ma bibliographie a saturé la mémoire de (Xe)LaTeX

Résumé du bug

Recherche de l'origine [1]

Recherche de la cause

Fonctionnement interne de la bibliographie avec LaTeX + Biber

Analyse du fichier .bbl

Résolution du problème

Première solution : utiliser LuaLaTeX

Deuxième solution : augmenter la mémoire de XeLaTeX

Troisième solution : éviter d'avoir deux bibliographies triées

En guise de conclusion

Polyglossia et XeLaTeX 3.14159265-2.6-0.99996 (TeXLive 2016)

Le problème

La solution

Catalague feature of biblatex-manuscripts-philology repaired with biblatex 3.4

Bug avec polyglossia 1.42.4

Le problème

La solution

biblatex 3.3 breaks the catalog feature of biblatex-manucripts-philology

Analyse du fichier `.bbl`