Source : https://tex.stackexchange.com/questions/755512/status-of-the-tabularray-package Son auteur (Jianrui Lyu) a annoncé par courriel privé (à une personne qui s’inquiétait de voir le dépôt GitHub du package GitHub - TeXackers/tabularray: Typeset tabulars and arrays with LaTeX3 · GitHub mis en statut « archivé ») ne plus maintenir son package. Rappel : https://www.youtube.com/watch?v=akOta7NHkUo (présentation du package par Paul Gaborit pour l’association GUTenberg). Il faut espérer que quelqu’un sera en mesure de reprendre le flambeau. Ou alors cela pourrait passer sous l’égide de The LaTeX Project Team, qui prend déjà en charge de nombreux packages « essentiels » (babel, hyperref, xcolor, mathtools, fontspec) ? La charge de travail risque d’être assez lourde pour une équipe déjà bien occupée. Le package a reçu une (dernière ?) mise à jour hier, avec la version 2025C 2025-11-27. Ce package qui pose des bases modernes pour la création de tableaux est une vraie pépite. Les autres packages ( CTAN: Contributor Jianrui Lyu ) de cet auteur semblent encore maintenus ( lvjr · GitHub ).
Le 28/11/25 à 13h38, quark67 a écrit :
Source : https://tex.stackexchange.com/questions/755512/status-of-the-tabularray-package Son auteur (Jianrui Lyu) a annoncé par courriel privé (à une personne qui s’inquiétait de voir le dépôt GitHub du package GitHub - TeXackers/tabularray: Typeset tabulars and arrays with LaTeX3 · GitHub mis en statut « archivé ») ne plus maintenir son package.
Argh !
Et dire que j’ai passé un temps certain à adapter mon cours LaTeX de façon à, comme Paul Gaborit, ne plus présenter la construction des tableaux que via ce package. Pour ceux que ça intéresserait, ça se trouve ici :
Rappel : https://www.youtube.com/watch?v=akOta7NHkUo (présentation du package par Paul Gaborit pour l’association GUTenberg).
C’est l’exposé de Paul qui m’a fait franchir le pas 
Il faut espérer que quelqu’un sera en mesure de reprendre le flambeau.
Yep!
Ou alors cela pourrait passer sous l’égide de The LaTeX Project Team, qui prend déjà en charge de nombreux packages « essentiels » (babel, hyperref, xcolor, mathtools, fontspec) ? La charge de travail risque d’être assez lourde pour une équipe déjà bien occupée.
Oui, c’est à espérer ! À moins qu’il y ait ici des volontaires
Le package a reçu une (dernière ?) mise à jour hier, avec la version 2025C 2025-11-27. Ce package qui pose des bases modernes pour la création de tableaux est une vraie pépite.
Je confirme, même si je trouve la syntaxe pas si régulière que cela. Je vous reproduis ci-dessous ce que je disais à Paul à ce sujet (désolé si ça n’est pas contextualisé mais je n’ai pas le temps d’adapter) :
Par exemple le fait que l’on puisse avoir :
cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {⟨caract.⟩}
cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {c=⟨m⟩,r=⟨n⟩}{⟨caract.⟩}
ou encore :
hline{⟨bordure(s)⟩}
hline{⟨bordure(s)⟩} = {⟨caract.⟩}
hline{⟨bordure(s)⟩} = {⟨segment(s)⟩}{⟨caract.⟩}
On pourrait s’attendre à ce que c=⟨m⟩,r=⟨n⟩ ou ⟨segment(s)⟩ qui
peuvent figurer ou ne pas figurer, soient à saisir entre crochets en
tant qu’arguments « optionnels », non ?
Puisque :
c=⟨m⟩,r=⟨n⟩indique quelles cellules sont concernées ;⟨segment(s)⟩indique quel(s) segment(s) (quelle(s) partie(s)) de(s) filet(s) sont concernés ;
j’aurais préféré les syntaxes suivantes :
cell[c=⟨m⟩,r=⟨n⟩]{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {⟨caract.⟩}
et :
hline[⟨segment(s)⟩]{⟨bordure(s)⟩} = {⟨caract.⟩}
Et, de même, comme les ⟨caract.⟩ sont optionnelles pour les filets,
j’aurais même préféré un truc du genre :
hline[⟨segment(s)⟩]{⟨bordure(s)⟩}[⟨caract.⟩]
Et même plus : par exemple, hline peut concerner plusieurs filets si
bien qu’il aurait été naturel que ça s’appelle hlines qui, sans
spécification de ⟨bordure(s)⟩, aurait concerné tous les filets
horizontaux, d’où une unique syntaxe pour les ces derniers :
hlines[⟨segment(s)⟩][⟨bordure(s)⟩][⟨caract.⟩]
ou, probablement mieux, via des clés/valeurs, par exemple :
hlines[
segments={⟨segment(s)⟩},
index={⟨bordure(s)⟩},
characteristics={⟨caract.⟩}
]
Et, de même pour les cellules :
cells[
colspan=⟨m⟩,
rowspan=⟨n⟩,
rowindex={⟨ligne(s)⟩},
columns={⟨colonne(s)⟩},
characteristics={⟨caract.⟩}
]
Les autres packages ( CTAN: Contributor Jianrui Lyu ) de cet auteur semblent encore maintenus ( lvjr · GitHub ).
Oui, c’est assez étonnant.
Merci pour ces commentaires. En effet, mon propre message avait été reçu dans la boite des spams et je me suis dit que finalement peut-être personne ne l’a vu. Il était question d’un passage du format mail au format forum, cela réglerait le problème du spam (et aussi, il faut bien le dire, de la taille assez réduite pour les éventuelles pièces jointes, qui ne correspond plus trop à ce qui se fait 20 ou 30 ans après la création de cette mailing-liste, surtout depuis que les courrielleurs se sont mis à créer des mails avec du HTML et des images). Cela prendra le temps qu’il faudra, sachant qu’il n’y a que des bénévoles qui font tourner cela, mais ça sera accueilli avec grand soulagement ;). Je place quelques commentaires plus bas, au fil du texte. Le 1 déc. 2025 à 18:58, Denis Bitouzé xyz@xyz.tld a écrit : Le 28/11/25 à 13h38, quark67 a écrit : Source : https://tex.stackexchange.com/questions/755512/status-of-the-tabularray-package Son auteur (Jianrui Lyu) a annoncé par courriel privé (à une personne qui s’inquiétait de voir le dépôt GitHub du package GitHub - TeXackers/tabularray: Typeset tabulars and arrays with LaTeX3 · GitHub mis en statut « archivé ») ne plus maintenir son package. Argh ! Et dire que j’ai passé un temps certain à adapter mon cours LaTeX de façon à, comme Paul Gaborit, ne plus présenter la construction des tableaux que via ce package. Pour ceux que ça intéresserait, ça se trouve ici : ┌──── │ Conférence n°4 : tableaux (package tabularray), unités, listings informatiques — MT2E Dunkerque └──── Cool, merci pour le partage ! Rappel : https://www.youtube.com/watch?v=akOta7NHkUo (présentation du package par Paul Gaborit pour l’association GUTenberg). C’est l’exposé de Paul qui m’a fait franchir le pas 
C’est réellement un très bon exposé, très pédagogique. Le package a reçu une (dernière ?) mise à jour hier, avec la version 2025C 2025-11-27. Ce package qui pose des bases modernes pour la création de tableaux est une vraie pépite. Je confirme, même si je trouve la syntaxe pas si régulière que cela. Je vous reproduis ci-dessous ce que je disais à Paul à ce sujet (désolé si ça n’est pas contextualisé mais je n’ai pas le temps d’adapter) : ┌──── │ Par exemple le fait que l’on puisse avoir : │ │ ┌──── │ │ cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {⟨caract.⟩} │ │ cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {c=⟨m⟩,r=⟨n⟩}{⟨caract.⟩} │ └──── │ │ ou encore : │ │ ┌──── │ │ hline{⟨bordure(s)⟩} │ │ hline{⟨bordure(s)⟩} = {⟨caract.⟩} │ │ hline{⟨bordure(s)⟩} = {⟨segment(s)⟩}{⟨caract.⟩} │ └──── │ │ On pourrait s’attendre à ce que c=⟨m⟩,r=⟨n⟩ ou ⟨segment(s)⟩ qui │ peuvent figurer ou ne pas figurer, soient à saisir entre crochets en │ tant qu’arguments « optionnels », non ? │ │ Puisque : │ │ - c=⟨m⟩,r=⟨n⟩ indique quelles cellules sont concernées ; │ - ⟨segment(s)⟩ indique quel(s) segment(s) (quelle(s) partie(s)) de(s) │ filet(s) sont concernés ; │ │ j’aurais préféré les syntaxes suivantes : │ │ cell[c=⟨m⟩,r=⟨n⟩]{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {⟨caract.⟩} Oui, ça se défend, mais l’intention de l’auteur semble avoir été celle-ci : pour cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {c=⟨m⟩,r=⟨n⟩}{⟨caract.⟩} la documentation indique (page 20) : cell{i}{j}={}{} Positionner {c=⟨m⟩,r=⟨n⟩} à gauche, sous forme d’option ne correspond pas vraiment au sens voulu par l’auteur. Avec la forme cell{i}{j}={}{}, à gauche du signe égal on indique les cellules concernées, et à droite ce qui est fait sur ces cellules. En particulier avec {c=⟨m⟩,r=⟨n⟩} on demande une fusion , à partir de la cellule positionnée en {i}{j}, sur m colonnes et n lignes. Puis on précise d’éventuels styles. Dans la première paire d’accolades à droite du signe =, il ne peut y avoir que les clés r et c (présentées en table 2.7 de la documentation), correspondant à une plage (je ne sais pas si c’est la meilleure traduction de l’anglais span ). On pourrait alors plutôt imaginer une syntaxe telle que cell{i}{j}=[]{}, mais cela n’a pas été choisi par l’auteur du package. Notons toutefois que cell n’est pas le nom d’une commande et l’élément à droite du signe = encore moins. Toutes les clés auraient pu être placées sous la même unique paire d’accolades comme cell{i}{j}={c=⟨m⟩,r=⟨n⟩,} mais il est probable que la séparation en deux parties distinctes permet de mieux lire les fusions de cellules plutôt qu’avec des clés r et c perdues au milieu d’autres clés dans un {} global. Ceci étant, je vois que dans les spécificateurs de colonnes, il y a bien la syntaxe […] qui est employée pour spécifier des options sur la manière d’afficher les barres verticales, comme dans la section 1.8 de la documentation (Hlines and vlines) : \begin{tblr}{|l|[dotted]|[2pt]c|r|[solid]|[dashed]|} De même en section 3.7 Child indexers and selectors, on découvre la syntaxe every[]{}{} qui elle respecte la mise entre crochet d’un argument optionnel. Je ne trouve pas d’exemple dans le manuel correspondant à hline{⟨bordure(s)⟩} (confusion avec la commande avec la contre-barre oblique \hline ?) mais bien ceux correspondant à hline{⟨bordure(s)⟩} = {⟨caract.⟩} hline{⟨bordure(s)⟩} = {⟨segment(s)⟩}{⟨caract.⟩} par exemple : hline{1,Z} = {2pt} Le code du package est moderne (avec LaTeX 3), mais effectivement la syntaxe est un peu touffue et variable… (non, je n’ai pas dit « incohérente », mais je comprends que certains puissent le penser). Je suppose que sur les premières versions, où il y avait moins de possibilités, c’était plus clair. Les autres packages ( CTAN: Contributor Jianrui Lyu ) de cet auteur semblent encore maintenus ( lvjr · GitHub ). Oui, c’est assez étonnant. Il avait quitté tex.SE il y a quelques années car quelqu’un avait lancé une « accusation » comme quoi cet auteur aurait « acheté » des évaluations (les étoiles) sur la page du CTAN consacré à son package. Sur sa page d’utilisateur (sur tex.SE) il a indiqué qu’il reviendra lorsque son package aura 1000 évaluations (façon de dire qu’il ne va pas créer 1000 comptes pour s’auto-attribuer des évaluations). Il s’est peut-être encore passé quelque chose, cette fois non publiquement. Il y a un certain nombre d’ issues qui avaient été ouvertes sur sa page du CTAN, j’espère que ce n’est pas cela qui a fini par le décourager. C’est un package qui fait pas mal de choses, et utilisé par pas mal de monde, il est naturel que des trucs ne fonctionnent pas comme prévu car on ne peut pas forcément penser à toutes les situations, et donc des personnes remontent ces bugs. L’un des rapports de bugs (ou de suggestions) le plus récent demandait à ce que le manuel comporte une section introductive plus claire, expliquant la notion de type de colonnes qui quelqu’un qui n’aura jamais vu ces notions. Ça peut décourager un auteur (rédiger une documentation est la partie la moins agréable pour l’auteur d’un outil), même si la personne qui a formulé la demande l’a fait dans des termes polis. Le maintien du package est peut-être désormais trop lourd pour l’auteur qui a peut-être moins de temps maintenant. Bref, la situation est ce qu’elle est, et à moins d’un changement d’avis de la part de son auteur d’origine, il faut espérer que le package soit repris par quelqu’un de motivé et qui a les connaissances pour naviguer dans le code.
Le 1 déc. 2025 à 18:58, Denis Bitouzé xyz@xyz.tld a écrit :
Le 28/11/25 à 13h38, quark67 a écrit :
Les autres packages ( CTAN: Contributor Jianrui Lyu ) de cet auteur
semblent encore maintenus ( lvjr · GitHub ).Oui, c’est assez étonnant.
Denis
Cela n’a pas trop duré. Le 20 décembre dernier, nouvelle salve de packages abandonnés par cet auteur :
– codehigh (CTAN: Package codehigh) : archivé (GitHub - lvjr/codehigh: Highlight codes and demos with l3regex and lpeg · GitHub) ;
– functional (CTAN: Package functional) : archivé (GitHub - lvjr/functional: Intuitive functional programming interface for LaTeX2 · GitHub) ;
– pegmatch (CTAN: Package pegmatch) : archivé (GitHub - lvjr/pegmatch: Parsing Expression Grammars for TeX · GitHub) ;
– randexam (CTAN: Package randexam) : archivé (GitHub - lvjr/randexam: Make an exam paper and its randomized variants · GitHub).
Il en reste quelques-uns qui sont encore maintenus par cet auteur, mais la tendance n’est pas à l’optimisme. Espérons simplement un manque de temps, et rien de plus grave.
Le 02/12/25 à 16h36, quark67 a écrit :
Il était question d’un passage du format mail au format forum, cela réglerait le problème du spam (et aussi, il faut bien le dire, de la taille assez réduite pour les éventuelles pièces jointes, qui ne correspond plus trop à ce qui se fait 20 ou 30 ans après la création de cette mailing-liste, surtout depuis que les courrielleurs se sont mis à créer des mails avec du HTML et des images). Cela prendra le temps qu’il faudra, sachant qu’il n’y a que des bénévoles qui font tourner cela, mais ça sera accueilli avec grand soulagement ;).
Nous y travaillons avec l’aide (remarquable !) de bénévoles qui se sont proposés lors de la dernière assemblée générale de l’association GUTenberg. Nous étudions deux solutions :
- Discourse : éprouvé mais assez lourd et livré de façon mal commode à « containeriser » ;
- Flarum (https://flarum.org/) : léger et « containerisable », mais souffrant (a priori) de certaines limitations, à commencer par la possibilité, pour les réfractaires aux interfaces Web, de l’utiliser comme une mailing liste.
Le 1 déc. 2025 à 18:58, Denis Bitouzé xyz@xyz.tld a écrit :
Je confirme, même si je trouve la syntaxe pas si régulière que cela. Je vous reproduis ci-dessous ce que je disais à Paul à ce sujet (désolé si ça n’est pas contextualisé mais je n’ai pas le temps d’adapter) :
┌──── │ Par exemple le fait que l’on puisse avoir : │ │ ┌──── │ │ cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {⟨caract.⟩} │ │ cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {c=⟨m⟩,r=⟨n⟩}{⟨caract.⟩} │ └──── │ │ ou encore : │ │ ┌──── │ │ hline{⟨bordure(s)⟩} │ │ hline{⟨bordure(s)⟩} = {⟨caract.⟩} │ │ hline{⟨bordure(s)⟩} = {⟨segment(s)⟩}{⟨caract.⟩} │ └──── │ │ On pourrait s’attendre à ce que
c=⟨m⟩,r=⟨n⟩ou⟨segment(s)⟩qui │ peuvent figurer ou ne pas figurer, soient à saisir entre crochets en │ tant qu’arguments « optionnels », non ? │ │ Puisque : │ │ -c=⟨m⟩,r=⟨n⟩indique quelles cellules sont concernées ; │ -⟨segment(s)⟩indique quel(s) segment(s) (quelle(s) partie(s)) de(s) │ filet(s) sont concernés ; │ │ j’aurais préféré les syntaxes suivantes : │ │ cell[c=⟨m⟩,r=⟨n⟩]{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {⟨caract.⟩}Oui, ça se défend, mais l’intention de l’auteur semble avoir été celle-ci : pour cell{⟨ligne(s)⟩}{⟨colonne(s)⟩} = {c=⟨m⟩,r=⟨n⟩}{⟨caract.⟩}
la documentation indique (page 20) : cell{i}{j}={}{}
Positionner {c=⟨m⟩,r=⟨n⟩} à gauche, sous forme d’option ne correspond pas vraiment au sens voulu par l’auteur.
Avec la forme cell{i}{j}={}{}, à gauche du signe égal on indique les cellules concernées, et à droite ce qui est fait sur ces cellules. En particulier avec {c=⟨m⟩,r=⟨n⟩} on demande une fusion , à partir de la cellule positionnée en {i}{j}, sur m colonnes et n lignes. Puis on précise d’éventuels styles.
Dans la première paire d’accolades à droite du signe =, il ne peut y avoir que les clés r et c (présentées en table 2.7 de la documentation), correspondant à une plage (je ne sais pas si c’est la meilleure traduction de l’anglais span).
Il n’empêche que, traditionnellement, en LaTeX, ce qui peut figurer ou pas est entre paires de crochets, pas entre paires d’accolades.
On pourrait alors plutôt imaginer une syntaxe telle que cell{i}{j}=[]{}, mais cela n’a pas été choisi par l’auteur du package.
C’est bien ce que je lui reproche ! 
Notons toutefois que cell n’est pas le nom d’une commande et l’élément à droite du signe = encore moins. Toutes les clés auraient pu être placées sous la même unique paire d’accolades comme cell{i}{j}= {c=⟨m⟩,r=⟨n⟩,}
Oui.
mais il est probable que la séparation en deux parties distinctes permet de mieux lire les fusions de cellules plutôt qu’avec des clés r et c perdues au milieu d’autres clés dans un {} global.
En effet.
Ceci étant, je vois que dans les spécificateurs de colonnes, il y a bien la syntaxe […] qui est employée pour spécifier des options sur la manière d’afficher les barres verticales, comme dans la section 1.8 de la documentation (Hlines and vlines) : \begin{tblr}{|l|[dotted]|[2pt]c|r|[solid]|[dashed]|}
De même en section 3.7 Child indexers and selectors, on découvre la syntaxe every[]{}{}
qui elle respecte la mise entre crochet d’un argument optionnel.
Yep.
Je ne trouve pas d’exemple dans le manuel correspondant à
hline{⟨bordure(s)⟩} (confusion avec la commande avec la contre-barre oblique \hline ?)
Pas compris.
mais bien ceux correspondant à hline{⟨bordure(s)⟩} = {⟨caract.⟩} hline{⟨bordure(s)⟩} = {⟨segment(s)⟩}{⟨caract.⟩}
par exemple : hline{1,Z} = {2pt}
Le code du package est moderne (avec LaTeX 3), mais effectivement la syntaxe est un peu touffue et variable… (non, je n’ai pas dit « incohérente », mais je comprends que certains puissent le penser).
[…]
Il s’est peut-être encore passé quelque chose, cette fois non publiquement. Il y a un certain nombre d’issues qui avaient été ouvertes sur sa page du CTAN, j’espère que ce n’est pas cela qui a fini par le décourager.
J’ai été de ceux qui ont ouvert un certain nombre d’issues. L’auteur
réagissant parfois de façon assez peu ouverte au dialogue, il m’est
arrivé d’insister (gentiment), certaines fois avec succès
L’un des rapports de bugs (ou de suggestions) le plus récent demandait à ce que le manuel comporte une section introductive plus claire, expliquant la notion de type de colonnes qui quelqu’un qui n’aura jamais vu ces notions. Ça peut décourager un auteur (rédiger une documentation est la partie la moins agréable pour l’auteur d’un outil), même si la personne qui a formulé la demande l’a fait dans des termes polis.
Je doute que ce soit le nombre et ce genre d’issues qui aient pu lui faire jeter l’éponge.
Le maintien du package est peut-être désormais trop lourd pour l’auteur qui a peut-être moins de temps maintenant.
Oui mais il est curieux qu’il ait choisi de continuer à maintenir ses autres packages moins utiles et moins emblématiques (mais, certes, probablement plus faciles à gérer).
Bref, la situation est ce qu’elle est, et à moins d’un changement d’avis de la part de son auteur d’origine, il faut espérer que le package soit repris par quelqu’un de motivé et qui a les connaissances pour naviguer dans le code.
J’espère par exemple que le très compétent Yukai Chou (alias muzimuzhi) en reprendra la maintenance comme il l’a fait pour thmtools. Je constate d’ailleurs qu’il a récemment créé un « fork » de ce tabularray :
┌──── │ GitHub - muzimuzhi/tabularray: Typeset tabulars and arrays with LaTeX3 · GitHub └────
Merci pour ces commentaires.
Padkoi
Denis
Je découvre cette information, c’est terrible.
A-t-on des nouvelles?