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.

Introduction à l'utilisation de LaTeX pour mettre en forme une édition critique : supports de formation

Maïeul — 2019-07-01T08:11:54Z

Vous trouverez ci-dessous les supports pour ma formation à l'utilisation de LaTeX pour la mise en page d'édition critique faite à Lyon le 1^er juillet 2019.

Introduction à l'utilisation de LaTeX pour mettre en forme une édition critique : supports de formation (Lyon 2019)

Le code du diaporama Beamer est disponible sur Framagit.

Introduction à l'utilisation de LaTeX pour mettre en forme une édition critique (bis repetitia)

Maïeul — 2019-06-17T15:40:03Z

En amont de la rencontre annuelle de l'AELAC, je donne avec ma collègue Caroline Macé une formation sur « les outils numériques pour l'édition critique ». Cela aura lieu le 1^er juillet à Lyon à partir de 14h. Une inscription préalable est nécessaire

Cette formation comportera deux parties : une introduction généraliste en binôme de panorama sur ce que le numérique peut et ne peut pas apporter à l'édition critique, puis deux formations en parallèle sur la mise en page des éditions critiques : l'une par Caroline Macé sur Classical Text Editor, l'autre par moi-même sur LaTeX.

Je mettrai en ligne les documents de formation.

Stage LaTeX Dunkerque : Git

Maïeul — 2019-06-12T06:00:00Z

Je présente au Stage LaTeX de Dunkerque une initiation à Git. Vous trouverez ci-dessous mon support de présentation.

Présentation sur l'utilisation de Git

Comme d'habitude, les sources sont sur Framagit.

Ma politique de branches avec Git

Maïeul — 2019-06-02T17:39:33Z

En préparant mon intervention sur Git au Stage LaTeX de juin, je me suis dit qu'il pouvait être utile que je résume, succinctement, ma politiquement de branchement avec Git.

Elle n'a rien de très original, mais je la trouve pratique, et je me la suis plus ou moins construite avec le temps, notamment à cause de mon travail sur (r)(e)ledmac.

Principe numéro 1 : la branche `master` doit être utilisable à tout moment

Contrairement à SVN où le trunk sert souvent de branche de développement, la facilité de créer des branches en git fait qu'il vaut mieux garder une branche master toujours prête à fonctionner.

C'est pourquoi je ne commite jamais directement dans master, sauf pour corriger des coquilles dans le manuel.

Principe numéro 2 : une branche par `issue`

Pour chaque issue (ticket) ouvert, je crée une branche homonyme issueXXX où XXX est le numéro de l'issue.

Le premier commit de la branche contient un exemple complet minimal, permettant de cerner le problème.

Le dernier commit contient l'effacement de cet exemple, ainsi que l'enregistrement des logs de changement dans le fichier .dtx. Son message habituel est changelog + fixe #XXX. Le fixe #XXX permet de fermer automatiquement l'issue lors de la fusion dans master.

Je demande à la personne ayant ouvert l'issue de tester à partir de ces branches.

Si la résolution d'un ticket dépend de la résolution d'un autre ticket, je fusionne d'une branche à l'autre.

Si une personne rouvre une issue fermée, deux solutions :

soit je considère qu'il s'agit en fait d'un problème différent, et dans ce cas je demande de rouvrir une nouvelle issue ;
soit j'avais mal résolu le problème, et dans ce cas je crée une branche issueXXX-bis.

Principe numéro 3 : jamais de rebasage ou de fast-forward, toujours de la fusion de branche

Le principe de créer des branches est de pouvoir faire des développements parallèles. Il importe que la trace de ces développements parallèles soit conservée même une fois finis les développements. C'est pourquoi je ne rebase jamais les branches une fois un développement achevé, et je refuse les fast-forward.

Ainsi qu'expliqué ailleurs, le rebasage ne devrait être conservé que pour gérer le cas où mon dépôt distant et mon dépôt local n'ont plus le même historique. Comme je travaille quasiment seul, cela m'arrive rarement.

J'ai donc dans mon .gitconfig global les lignes suivantes :

 [pull] ff = only rebase = preserve [merge] ff = false

Principe numéro 4 : une branche par release

Avant de sortir (« releaser ») une nouvelle version, je crée une branche. Le nom de cette branche correspond au numéro de version de la future release. Dans le cas de reledmac, comme en plus reledpar n'a pas le même numéro de version, j'utilise un tiret pour séparer les deux numéros. Cela donne donc x1.y1.z1-x2-y2-z2.

Dans cette branche :

je fusionne les branches fonctionnelles / de débogage ;
je corrige le cas échéant le changelog, pour adapter à la date effective de sortie ;
je procède aux tests automatiques.

Puis je fusionne avec master, d'où je prépare la sortie effective.

Principe numéro 5 : une branche par version majeure

Avant reledmac, ils y avaient eledmac et ledmac. Dans mon système de codification, reledmac est la version 2, eledmac la version 1 et ledmac la version 0. J'ai donc une branche 1 et une branche 0 pour les rares cas où j'accepte d'intervenir sur ces anciennes versions [1].

Principe numéro 6 : une branche pour la relecture de l'anglais

Comme je demande régulièrement à des personnes de relire l'anglais et le manuel de reledmac/reledpar, j'ai créé une branche english2 [2]. Cette branche contient l'état des fichiers après la dernière relecture par une correcteurtrice. Je m'en sers pour proposer de ne relire que les nouvelles modifications en comparant english2 et master.

Principe numéro 7 : ne pas conserver les branches fusionnées

Une fois une branche fusionnée, je la supprime en local comme en distant.

Appendice : principe de numérotation des tags et des release

J'utilise un système simple de numérotation sur le mode x.y.z

Un changement de x indique une rupture majeure, impliquant de grands changements. Dans le monde LaTeX, je change également le nom, pour faciliter la compatibilité ascendante des documents.
Un changement de y indique de nouvelles fonctionnalités.
Un changement de z indique une correction de bug.
Parfois j'ajoute une lettre (a, b, c, etc.) pour indiquer une simple correction dans le manuel.

Mes tags correspondent simplement au numéro de version (pas de v. devant). Dans le cas de reledmac-reledpar, comme les deux paquets sont liés sur le dépôt et en distribution, mais sont néanmoins distincts, mes tags ont la forme macx1.y1.z1-parx2.y2.z2.

J'ai enfin des tags sur tests abandonnés, que je garde plus pour me dire « si jamais il me revient à l'idée de reprendre ce projet ».

[1] Principalement pour corriger des ruptures de comptabilité apportées par les évolutions de LaTeX.

[2] 2 parce que cela concerne reledmac, cf. plus haut.

Stage LaTeX à Dunkerque

Maïeul — 2019-05-06T16:58:29Z

Comme chaque année, l'IUT de génie thermique de Dunkerque, ou plus exactement Denis Bitouzé, organise un stage d'une journée. Cette année, le stage LaTeX aura lieu le 12 juin prochain.

Le stage nécessite une inscription préalable, et ne coût que 6 € de participation aux frais.

J'y présenterai deux interventions :

biblatex et biber : gérer sa bibliographie avec des outils ﬂexibles et modernes
Gérer son historique de ﬁchiers LaTeX avec Git

Présentation de LaTeX pour les éditions critiques au stage XSLT de Lyon

Maïeul — 2019-04-23T12:00:00Z

Ainsi qu'annoncé, je présent LaTeX pour les éditions critiques à un stage XSLT à Lyon. Vous trouverez ci-dessous mes supports de présentation.

Outre un diaporama Beamer, j'ai produit un exemple d'édition critique avec LaTeX, en reprenant l'édition XML d'Andromaque, de Racine, qui sert de fil rouge à la session.

N'ayant pas eu le temps d'appréhender le XML et le XSLT de la session, l'exemple n'est pas complet, et ne contient que quelques élèments parmis d'autres pour édition critique en LaTeX.

Support de présentation

Exemple d'édition critique avec LaTeX - code source

Exemple d'édition critique avec LaTeX - Pdf final

Mon intervention, comme l'ensemble des supports du stage, se trouve sur Github.

LaTeX pour les éditions critiques : une présentation et une formation prochainement

Maïeul — 2019-03-27T16:49:12Z

J'interviendrait prochainement à Lyon, à deux reprises, pour parler de LaTeX pour les éditions critiques.

Une fois sous forme de conférence le 22 avril dans le cadre d'une session de formation au XSLT pour les éditions critiques. Attention, bien que mon intervention se fasse durant une session de formation, il s'agira belle et bien d'une simple intervention
Le 1^er juillet prochain, dans une journée « Mots savants et outils numériques de l'édition critique », en amont de la rencontre annuelle de l'Association pour l'étude de la littérature apocryphe chrétienne (AELAC). Après une introduction commune avec ma collègue Caroline Macé sur l'ensemble des outils numériques pour l'édition critique, deux ateliers en parallèle seront proposé : l'un sur LaTeX, l'autre sur Classical Text Editor. Il s'agira donc d'ateliers pratiques, et l'inscription est obligatoire, via le site de l'AELAC.

Comme d'habitude, je mettrai en temps utile les supports de formation sur le présent site.

Using LaTeX to typeset critical editions

Maïeul — 2019-02-25T07:15:00Z

I was invited to a learning session in organized by the "Research Infrastructure on Religious Studies" to animate a workshop about LaTeX and cricital edition.

Here, you will find the beamer of the workshop, which is followed by a practical training, using overleaf.

Introduction to the use of LaTeX for critical edition

Instruction for the workshop

The code of the beamer is available on https://framagit.org/maieul/introduction-edition-critique-latex/tree/Bologna2019

Enregistrements vidéo de la journée d'étude « Encoder numériquement une édition critique »

Maïeul — 2019-02-06T16:18:54Z

À la demande de plusieurs personnes, nous avons procédé à un enregistrement vidéos des interventions lors de la journée d'étude « Encoder numériquement une édition critique ».

Avant toute chose, je tiens à remercier mon collègue Francis Mobio pour m'avoir formé à la capture vidéo (les problèmes de capture sont de moi !) et avoir effectué le montage final.

Tara Andrews ayant été malade elle n'a pu venir. Elle nous a envoyé ses diapositives, qui ont été présentées par Violeta Seretan, mais nous n'avons pas procédé à un enregistrement.

Enfin, l'enregistrement de mon intervention s'est interrompue sur la fin. C'est pourquoi les dernières questions ne sont pas enregistrées.

Notez que les vidéos sont hébergées sur les serveurs de l'Université de Lausanne, et que certains plugins de protection de la vie privée pourraient éventuellement les bloquer.

Maïeul Rouquette — Introduction

Caroline Macé — Les éditions critiques : un bref survol terminologique et historique

Marjorie Burghart — Éditions critiques en XML-TEI : l'enjeu de la multimodalité

Maïeul Rouquette — Produire une édition critique avec LaTeX, ou le primat de la typographie