Vous en souvient-il ? En deux mille vingt-cinq, qpad nous présentait Typst, un nouveau système de composition de documents qui se posait en concurrent de LaTeX.
Depuis, Typst semble avoir grandi, en s’assortissant d’une galaxie (pardon, un univers) de paquets tiers. En fait, j’ai surtout l’impression qu’il a gagné en notoriété, ou en quantité de mouvement, pour le dire comme les anglophones. C’est l’occasion de présenter à nouveau ce système de composition.
Sommaire
- Un système de composition de documents
- Concurrent à LaTeX
- Impressions d’un LaTeXnicien
- Un bel avenir ?
Un système de composition de documents
Typst est donc un système de composition de documents. Comme LaTeX, il est non-visuel, c’est-à-dire qu’on code son document qui est ensuite compilé en PDF.
Concrètement, l’outillage se compose, au choix :
- du compilateur Typst, sous licence Apache ;
- de l’application Web, non libre, qui fournit un éditeur intégré et une visualisation en temps réel.
Concurrent à LaTeX
Typst partage plusieurs caractéristiques avec LaTeX dont il est ouvertement inspiré :
- c'est un système non visuel avec un langage dédié ;
- il est conçu pour permettre d’écrire des documents scientifiques.
Bien que je n’aie pas vérifié ce point, il me semble probable qu’il utilise également quelques algorithmes de mise en page assez incontournables, définis par Donald Knuth pour TeX, par exemple pour la coupure des lignes d’un paragraphe.
Il s’écarte évidemment de LaTeX sur plusieurs aspects, sinon ce ne serait pas vraiment un nouveau système de composition :
- c’est un système autonome, contrairement à LaTeX qui est construit sur TeX ;
- il est conçu dès le départ avec des préoccupations actuelles (Unicode, PDF…) ;
- il est conçu comme un langage humainement compréhensible, là où TeX semble franchement ésotérique.
Impressions d’un LaTeXnicien
Quand on arrive de LaTeX, l’impression est assez partagée, entre des différences significatives, de gros avantages et quelques inconvénients.
Le langage de texte
Le langage de base pour le texte est différent de LaTeX, mais ce n’est pas vraiment dérangeant dans la mesure où on parle seulement de paragraphes, de titres, de mise en emphase, de listes, etc. Bref, le genre de chose qu’on fait aussi bien en Markdown. D’ailleurs, Typst étant né après le développement des langages de balisage léger, sa syntaxe Typst est justement assez proche de Markdown, ce qui n’est pas désagréable :
= Titre de section
Voici du texte avec _une emphase_, *une emphase forte* et un `peu de code`.
À noter que cette syntaxe légère n’est en fait que du sucre syntaxique, et qu’on peut écrire la même chose en faisant explicitement appel à des fonctions nommées.
La compilation
Pour celles et ceux qui n’ont pas l’habitude de LaTeX, compiler un document un peu costaud, qui fait appel à quelques extensions, ça demande un temps de l’ordre d’une ou plusieurs secondes, et cela produit des centaines, voire des milliers de lignes de log. Pour avoir des références internes (sommaire, références à des images…) et externes (bibliographie), il faut lancer plusieurs fois la compilation.
Pour qui vient du monde LaTeX donc, la compilation par Typst est hallucinante. Une seule passe, même si en interne, Typst fait certainement au besoin plusieurs itérations. Quelques dizaines de millisecondes. Ok, c’était pour un document ultra-simple, mais les commentaires lisibles sur les Interwebz font généralement état d’un rapport d’un ou deux ordres de grandeur par rapport à LaTeX.
Le langage de configuration et d’extension
Là où ça change vraiment, c’est pour tout ce qui relève des réglages, des modèles, de la personnalisation ou de la programmation d’extensions. Là, ça n’a plus rien à voir avec TeX et LaTeX. À mon avis, ce n’est pas un mal dans la mesure où le langage TeX et les conventions utilisées pour le développement en LaTeX sont assez complexes, voire incompréhensibles.
Cela se ressent dans le code des extensions. À titre de comparaison, celui de la classe LaTeX lettre fait quelques milliers de lignes. Et c’est assez illisible pour qui ne connaît par TeX. Le code du modèle formalettre, qui n’est certes pas aussi complet mais qui fait très bien le travail de base d’une telle classe, fait une centaine de lignes, que je trouve relativement lisibles pour un béotien.
L’utilisation de paquets tiers
Les paquets tiers, hébergés sur l’univers Typst, sont téléchargés à l’utilisation. Par rapport à une distribution LaTeX qui pèse facilement plusieurs centaines de mébioctets, ça donne une vraie impression de légèreté.
La francisation
L’adaptation aux conventions en usage en langue française, ou dans les différents pays francophones, me semble encore assez incomplète.
Lorsqu’on passe un document en français, les changements de base s’effectuent bien : un sommaire s’appellera bien « Tables des matières » et les césures respecteront l’usage de la langue.
En revanche, cela n’adapte pas la mise en forme des paragraphes avec alinéa, et on attendrait en vain que des mots comme 1ᵉʳ, 2ᵉ ou Mme soient automatiquement mis en forme selon l’usage attendu. Et non, il n’y a pas de commandes définies pour cela. Pas encore, en tout cas, parce que je serais surpris que personne ne publie un jour un paquet proposant tout cela.
Les modèles
L’équivalent d’une classe LaTeX est un modèle Typst. Cela correspond à un type de document, par exemple un article, un rapport ou une lettre.
Typst ne semble pas proposer de modèles officiels. Il y en a en revanche par mal dans l’univers Typst, et le langage est conçu pour rendre la création d’un modèle assez accessible. Le troisième chapitre du tutoriel officiel traite justement de la création d’un modèle.
Un bel avenir ?
Typst a été conçu à partir de 2019 et a vraiment vu le jour en 2023. J’en ai entendu parler pour la première fois en mars 2023, dans le journal de qpad.
Les lacunes que j’avais alors remarquées et qui me retenaient de commencer à l’utiliser pour mes propres documents, semblent avoir été comblées pour l’essentiel. L’univers Typst, qui est le dépôt de paquets tiers, s’est largement rempli et semble bien jouer son rôle pour permettre aux utilisateurs de partager les extensions et modèles.
Le langage semble bien conçu :
- il joue correctement son rôle pour la mise en forme de documents et de contenu scientifique ;
- il est beaucoup plus humain que TeX et LaTeX lorsqu’il s’agit d’écrire des modèles et des extensions.
L’écosystème est également bien conçu et bien fourni et semble bien répondre aux attentes de la communauté, avec une légèreté bienvenue. Dans l’ensemble, j’ai l’impression que Typst est bien parti pour proposer un successeur sérieux à LaTeX. Je formule tout de même quelques interrogations :
- la distribution de paquets tiers, incontournable, semble intégralement centralisée et dépendante de l’univers Typst ;
- ce dernier, ainsi que Typst en général, est maintenu par l’entreprise allemande Typst GmbH dont le financement dépend de la vente d’abonnements aux formules premium de l’application Web : espérons que cela s’avère pérenne.
Aller plus loin
- Typst (302 clics)
- Tutoriel Typst (91 clics)
- Typst pour les utilisateurs LaTeX (89 clics)
- Référence Typst (30 clics)
- Univers Typst, le dépôt de paquest tiers (40 clics)
- Journal présentant Typst en 2023 (57 clics)
# Prononciation
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8 (+5/-0).
Au fait, j'ai oublié d'expliquer que Typst se prononce « taïpst » et non « taille-piste » par exemple.
Ce n'est pas le plus facile à prononcer pour un francophone, mais pas plus difficile que « hipster » par exemple.
[^] # Re: Prononciation
Posté par Tit . Évalué à 2 (+0/-0). Dernière modification le 03 septembre 2025 à 08:21.
C'est à dire ? à peu près tahipste ?
[^] # Re: Prononciation
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
C'est ça ! En une seule syllabe toutefois.
[^] # Re: Prononciation
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
On appelle ça une diphtongue.
[^] # Re: Prononciation
Posté par steph1978 . Évalué à 4 (+2/-0).
Pas sûr que "pst" ça puisse se prononcer sans y glisser une petite voyelle.
Et encore moins sans arroser l'audience de postillons.
[^] # Re: Prononciation
Posté par ElVirolo (site web personnel) . Évalué à 2 (+0/-0).
Si, c'est tout à fait possible :) C'est même courant en français, avec l'interjection « psst », qui se prononce [pst].
[^] # Re: Prononciation
Posté par steph1978 . Évalué à 3 (+1/-0).
J'ai écouté les prononciation sur https://fr.wiktionary.org/wiki/pst ; difficile de pas entendre 'psit'….
[^] # Re: Prononciation
Posté par ElVirolo (site web personnel) . Évalué à 2 (+0/-0).
Pourtant, il n'y a pas de [i], rien n'est voisé.
[^] # Re: Prononciation
Posté par thoasm . Évalué à 3 (+0/-0).
J'imagine que si tu fais durer le "s", avec les lèvres positionnées en anticipant le "t", on entend un truc hyper proche du "i" version chuchotée ?
[^] # Re: Prononciation
Posté par BAud (site web personnel) . Évalué à 2 (+1/-1). Dernière modification le 11 septembre 2025 à 09:47.
tu confonds avec le psshittt du bruit d'une canette de soda Breizh Cola fraîchement ouverte ;-)
# Inclusion des figures PDF
Posté par jch . Évalué à 6 (+5/-0).
Il y a quelques années, j'avais essayé de convertir quelques uns de mes documents LaTeX en Typst. J'avais buté sur une limitation : Typst ne permettait pas d'inclure des figures au format PDF. Il aurait donc fallu que je convertisse toutes mes figures en SVG.
Cette dépêche m'a fait vérifier de nouveau, et on dirait que la limitation n'existe plus depuis la version 0.14 de Typst. Je vais peut-être regarder de nouveau.
[^] # Re: Inclusion des figures PDF
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Convertir toutes les figures en SVG, ça n'avait rien de bien difficile.
Mais avec en plus les autres lacunes que Typst pouvait avoir à l'époque, et celles qu'il a peut-être encore selon ce que tu veux faire…
[^] # Re: Inclusion des figures PDF
Posté par jch . Évalué à 3 (+2/-0).
Pour qu'elles soient de nouveau converties en PDF lors de la mise en page? Désolé, je m'y refuse.
C'est pour mettre en page mes notes de cours, qui ressemblent à ça : https://www.irif.fr/~jch/enseignement/programmation-systeme.pdf. Je pense que ça devrait être faisable.
[^] # Re: Inclusion des figures PDF
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Très juste. Mais d'ailleurs, est-ce que l'implémentation récente de cette fonctionnalité ne ferait pas genre justement ça en interne ? :-/
[^] # Re: Inclusion des figures PDF
Posté par jch . Évalué à 2 (+1/-0).
Effectivement, il faudrait tester. Je ne peux pas installer une version récente en ce moment, tout ce que je peux confirmer, c'est que l'inclusion des PDF inclut les polices et génère du texte qu'on peut sélectionner, ce qui n'est pas le cas avec pdf2svg.
# formalettre
Posté par Brndan (site web personnel) . Évalué à 10 (+16/-0).
C’est moi qui ai commis formatlettre, cela fait plaisir de constater que c’est utile. Je l’utilise pour générer mes (nombreux) courriers administratifs, c’est bien plus rapide qu’avec LuaLateX ou XeLateX pour un rendu similaire.
La procédure de publication d’un paquet est pour le moins artisanale. Il faut forker le dépôt de tous les packages, le cloner, ajouter dans un dossier à part son package / et dans un sous-dossier la bonne version, faire une pull request sur GitHub, attendre la validation, attendre la publication. Ça mériterait sans doute d’être davantage pensé pour faciliter la vie des développeurs et développeuses du dimanche qui veulent simplement partager de petits paquets.
[^] # Re: formalettre
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Pour le dire autrement, l'univers Typst gagnerait à devenir un CTyAN. ;-)
Sinon, tu vas voir passer un paquet de rapports de bug sur formalettre, qui deviendront des PR d'ici quelques jours ou semaines. :-)
[^] # Re: formalettre
Posté par Brndan (site web personnel) . Évalué à 2 (+1/-0).
Avec plaisir. Pour t’assurer que tout cela soit traité convenablement, n’hésite pas à m’envoyer un e-mail, car les semaines prochaines seront denses.
[^] # Re: formalettre
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
En fait en y réfléchissant, entre ce monodépôt bizarre et l'espace de nom
preview, l'implémentation actuelle de l'univers Typst sent le truc vite fait histoire de release early un truc très attendu et de grande valeur pour le décollage de Typst.Ça devrait sûrement évoluer dans les années à venir.
[^] # Re: formalettre
Posté par p1ld7a . Évalué à 1 (+1/-0).
Hello,
Merci pour formalettre!
De mon cote, je ne connaissais pas ton package et j'utilise: https://github.com/pascal-huber/typst-letter-template qui fonctionne plutôt bien et comporte pas mal d'options.
Malheureusement, il n'est pas disponible sur Typst Universe, on dirait que le mainteneur n'est pas intéressé à le publier.
Bref, bonne continuation!
# Mon expérience
Posté par HSimpson . Évalué à 8 (+7/-0).
J’ai réalisé quelques documents pour le fun, et en ce moment, je suis en train de passer mes cours de odt à typ.
Pour souligner quelques différences (dans l’ordre où ça me vient, c’est-à-dire sans ordre) :
C’était juste mes 2c
[^] # Re: Mon expérience
Posté par Computer (site web personnel) . Évalué à 1 (+1/-0).
Qu'est-ce que ce sera quand on sera iso-Tex !
[^] # Re: Mon expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
À noter que le binaire en question inclut notamment les fontes utilisées par défaut.
[^] # Re: Mon expérience
Posté par Computer (site web personnel) . Évalué à 4 (+4/-0).
Ces pratiques de cochons !
[^] # Re: Mon expérience
Posté par jch . Évalué à 2 (+1/-0).
Concrètement, qu'est-ce qui t'a manqué ? (À part Tikz, que tu mentionnes déjà.)
[^] # Re: Mon expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7 (+4/-0).
Perso, je sais ce qui me manque : de quoi mettre en forme des textes en vers.
C'est à mon avis, dans TeX comme dans Typst, un manque dans le moteur lui-même, qui devrait être en mesure de gérer six types de contenu textuel de base :
Dans LaTeX, le paquet que j'utilise pour cela,
verse, détourne l'usage des listes. C'est possible dans un langage à macros, je ne suis pas sûr que ce soit vraiment faisable avec Typst. On peut aussi détourner l'usage du texte pré-formaté, mais avec des inconvénients significatifs (pas de fonctions ou de balisage possible, pas de césure).À noter que la langue anglaise est horriblement ambigüe quand on parle de vers. Le même mot verse désigne en effet, comme en français, les textes en vers en général, ainsi qu'une ligne d'un tel texte. Mais ce même mot verse peut aussi désigner une strophe, ou encore un couplet qui est un type particulier de strophe. Quant à un refrain, cela se dit chorus, ce qui peut également désigner un chœur. Bref, coder en langue anglaise une prise en charge des textes versifiés est un véritable enfer.
[^] # Re: Mon expérience
Posté par lejocelyn (site web personnel) . Évalué à 2 (+0/-0).
À noter que refrain se dit également "refrain" en anglais, d'après mes collègues américains, anglais et australiens à côté de moi. D'ailleurs j'ai publié un article en anglais où j'utilise le terme "refrain" (pour désigner les refrains chantés dans les narrations).
[^] # Re: Mon expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
Oui, et on peut aussi utiliser le terme français de couplet en anglais.
Heureusement, parce qu'avec les termes (plus courants et terriblement ambigus) de chorus et verse, on ne comprend plus rien lorsqu'on code un truc pour traiter des chansons.
[^] # Re: Mon expérience
Posté par Wawet76 . Évalué à 2 (+0/-0).
Pour quelqu'un qui ne connait pas vraiment TeX ni la poésie, c'est quoi le besoin spécifique pour les vers ?
Un paragraphe par strophe et un retour à la ligne par vers, ça ne fait pas l'affaire ?
[^] # Re: Mon expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
Alors, la première chose, c'est que dans ce genre de langage, comme en HTML d'ailleurs, les retours à la ligne sont normalement traités comme des espaces. Pour un texte en vers, il faut donc au expliciter chaque retour à la ligne, ce qui est au minimum assez casse-pied.
Typst fournit de quoi écrire des extraits de code informatique, en respectant entre autres les retours à la ligne, parce que, eh bien, dans cela c'est trop casse-pied.
Ensuite, si un vers est trop long, il faut le couper bien sûr, mais en l'indentant. Ça, c'est le plus contraignant. Il faut aussi pouvoir couper manuellement un vers où on veut.
Enfin, pour intégrer des poèmes dans un rapport ou un article en prose de façon pas trop moche, il faut également les centrer, mais attention, centrer chaque poème sur la page tout calant les vers individuels à gauche de leur poème.
[^] # Re: Mon expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
Ensuite, mais là c'est du raffinement, on peut vouloir numéroter les vers, indiquer que telle strophe est le refrain, telle strophe le premier couplet, etc.
Également, légender, numéroter et indexer les poèmes comme on le fait pour les figures, les tableaux ou les extraits de code.
[^] # Re: Mon expérience
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Tiens, d'ailleurs, il existe une deuxième mise en œuvre de Typst, en Haskell.
https://hackage.haskell.org/package/typst
Et l'indispensable pandoc, qui fait tout et la café, sait produire du Typst.
(Fin de la propagande haskellienne.)
[^] # Re: Mon expérience
Posté par jch . Évalué à 2 (+1/-0).
Je me trompe peut-être, mais je crois bien que c'est juste un parseur et un évaluateur d'expressions, pas un moteur de mise en page.
N'hésite pas, ça nous change un peu de la propagande Rust.
[^] # Re: Mon expérience
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
Cette bibliothèque vient de l’auteur de pandoc, et c’est justement celle que pandoc utilise pour prendre en charge le format de Typst.
# Les derniers mètres sont les plus durs
Posté par nojhan (site web personnel, Mastodon) . Évalué à 10 (+17/-0).
D'une certaine manière, c'est cool qu'il y ait de la concurrence ; mais d'un autre point de vue, je crains qu'on ne réinvente la roue, avec une série d'arguments naifs très classiques.
C'est un peu un lieu commun récurrent, en informatique, de voir des nouveaux projets commencer par dire qu'ils sont plus légers, plus rapides et plus simples que la concurrence établie.
Et inévitablement, ils finissent avec les mêmes problèmes que la concurrence (pensez à Linux, Python, Rust, Node, CMake… même LaTeX a commencé en disant ça, et j'ai moi-même commis ce genre d'erreur).
Cette naiveté transparait dans la dépêche, notamment sur le modèle de lettre qui est plus léger, mais n'a pas toutes les fonctionnalités. Je mettrais volontiers ma main à couper que, quand le modèle sera à fonctionnalités égales, la différence ne sera plus si flagrante. Cette différence de taille est probablement due au fait que ce sont les derniers mètres les plus durs.
Et c'est la même chose pour la gestion des plugins. Oui, c'est simple d'installer un binaire seul, et ça va vite à compiler. Mais déjà on voit que les problèmes commencent dans l'univers, et je vous prédis que c'est pas prêt de s'arrêter (regardez Python "batteries included" >_<), ni d'atteindre la qualité des distributions LaTeX.
Mon conseil : gardez en tête que les derniers mètres sont les plus difficiles, ne sous-estimez pas la quantité invraisemblable de taf que requiert la maintenance d'une distribution de plugins, réutilisez les codes/algos des ainés et ne faites pas de comparaisons hâtives.
[^] # Re: Les derniers mètres sont les plus durs
Posté par thoasm . Évalué à 9 (+6/-0).
Il y a quand même un atout, la syntaxe basique est moins lourde est plus familière et moins rebutante pour beaucoup de personnes qui étaient rebutées par LaTeX, la communauté pourrait inclure des personnes un peu différentes qui étaient plus attirées par des langages à balisage léger. Ce n'est pas forcément un détail et pourrait tirer les deux logiciels dans des directions légèrement différentes, en attirant plus facilement des développeurs qui n'auraient pas sauté le pas.
Il n'y a pas que la "légèreté", perçue ou pas, de la distribution logicielle ou de la compilation mais aussi de la rédaction qui compte, même perçue. TeX/LaTeX ont aussi un long historique, le démarrage de la base est antidéluvien et les efforts se sont un peu dispersés (on parle de LaTeX3 de nos jours ? Quelle distribution installer en 2025, comment s'y remettre après une longue pause, ou en est l'écosystème et sont les différents compilos ?).
Repartir sur autre chose, si effectivement on perd toute une partie du polissage, avec des idées un peu plus moderne pourrait avoir l'effet de se débarrasser d'une partie de la complexité qui est plus liée à l'historique qu'à une véritable nécessité ?
[^] # Re: Les derniers mètres sont les plus durs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9 (+6/-0).
Oui : si j'ai bien compris, LaTeX3 est maintenant un ensemble de fonctionnalités pour le développement d'extensions. J'en ai utilisé, c'est cool. Mais ça reste un truc très pointu, le développement d'extension. Chaque fois que je m'y replonge il me faut un moment pour me remettre dans le bain, et j'ai toujours du mal à me relire, malgré tout le mal que je me suis donné pour clarifier et commenter mon code.
TeX Live, sans hésiter. C'est celle qui est fournie par les différentes distributions GNU/Linux, et elle peut aussi être installée sur Windows et MacOS.
Pour l'utilisation simple, ça n'a pas vraiment changé. Enfin, des détails ont changé, on va voir des trucs un peu différents dans le préambule, mais le reste, c'est pareil, syntaxe et concepts inchangée.
Il y a XeTeX et XeLaTeX maintenant. Ça compile directement en PDF, ce qui était déjà le cas avec PDFTeX et PDFLaTeX. Mais la vraie différence, c'est que XeTeX et XeLaTeX utilisent des fontes OpenType (entre autres, mais en pratique, on va retenir OpenType, ce sont celles qui nous concernent le plus).
[^] # Re: Les derniers mètres sont les plus durs
Posté par zurvan . Évalué à 3 (+1/-0).
la syntaxe, d'accord c'est plus léger que LaTeX en revanche c'est dommage d'avoir "trop" simplifié, en reprenant les travers de markdown, notamment avec un caractère unique comme
=en début de ligne (là où c'est#avec md) pour signifier un entête, ou un unique*pour le gras, ils ne se sont pas dit que cela risquait de faire des clash avec des caractères existants dans le document ? Déjà qu'en markdown c'est pénible lorsqu'il y a un # en début de ligne pour une autre raison (hashtag notamment), on imagine qu'un = ce n'était pas très pertinent.« La censure est l'outil utilisé lorsque les mensonges perdent de leur pouvoir »
[^] # Re: Les derniers mètres sont les plus durs
Posté par lolop (site web personnel) . Évalué à 4 (+2/-0).
Un tel outil sera de toutes façons un compromis entre différents besoins (et différentes idées / préférences personnelles)…
Pour échapper un
=en début de ligne…\=.Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Les derniers mètres sont les plus durs
Posté par thoasm . Évalué à 3 (+1/-1).
Oui si on ne veut aucun problème d'échappement/d’ambiguïté faut pas prendre un langage textuel et plutôt se tourner vers libre office ou autre.
[^] # Re: Les derniers mètres sont les plus durs
Posté par lolop (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 05 septembre 2025 à 13:31.
(bis?)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Les derniers mètres sont les plus durs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+8/-0).
C'est vrai ? Je serais curieux de lire ça. En tout cas, à mon avis LaTeX souffre surtout d'être basé sur TeX, qui est un modèle de complexité. On fait absolument tout ce qu'on veut avec, mais ça ressemble à de la magie noire. Et le fait que ce soit un langage à macros me semble contribuer à le rendre très lent pour compiler des trucs un peu complexes.
Je suis d'ailleurs assez partagé sur les réalisations de Donald Knuth. C'est sans le moindre doute une référence en matière d'informatique théorique, mais avant d'avoir lu le TeXbook, TeX me semblait déjà complètement inhumain, et après l'avoir lu… c'est toujours le cas. À côté, même du Perl parait clair comme de l'eau.
Je suis d'ailleurs impressionné par les merveilles que les développeurs d'extensions arrivent à faire avec, je pense en particulier à des choses comme TikZ ou Beamer.
C'est vrai, mais seulement partiellement à mon avis. Ça dépend de quelle différence on parle. Lorsque le modèle Typst
formalettrefournira une fonctionnalité équivalente à celle de la classe LaTeXlettre, je parierais :Les fonctionnalités de la classe
lettre, ce n'est pas non plus quelque chose d'invraisemblable : formater une lettre avec expéditeur, destinataire, lieu, date, objet, références, salutation initiale, corps, salutation finale, signature, pièces jointes. Et une marque de pliage, à mon avis très mal placée sur la page d'ailleurs. Ah, et ça permet de formater des télécopies aussi, ce qui n'a plus aucun intérêt aujourd'hui : ça, on pourra s'en dispenser.[^] # Re: Les derniers mètres sont les plus durs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+8/-0).
Je suis en train de travailler à compléter le modèle Typst
formalettrede Brndan pour y implémenter des trucs qui me semblent manquer. Pour avoir déjà travaillé à des extensions LaTeX, je ne peux que confirmer que c'est sans commune mesure en terme de facilité et de lisibilité de code.J'ai passé des années à travailler avec LaTeX. J'ai lu le TeXBook, j'ai codé quelques extensions perso, dont une qui utilise vraiment des structures de programmation, avec des exécutions conditionnelles par exemple. J'ai toujours eu peur de me lancer dans ce genre de programmation, et je crains toujours de devoir m'y remettre. Même pour corriger ou améliorer mon propre code. Pour le dire autrement, la barrière à l'entrée de LaTeX est déjà grande pour simplement écrire, mais alors pour programmer, elle est immense.
Là, ça fait quelques jours que je pratique Typst, et je suis en mesure de modifier largement une extension existante. Et je compte bien implémenter un Typst les trucs perso que je m'étais fait en LaTeX.
Améliorer
formalettre, me direz-vous, ce n'est pas spécialement compliqué, ce modèle n'est en effet pas quelque chose de très complexe. C'est vrai, mais je serais incapable de faire la même chose pour la classe LaTeXlettre. Pas sans y passer dix fois plus de temps en tout cas.[^] # Re: Les derniers mètres sont les plus durs
Posté par bistouille . Évalué à 5 (+3/-0).
Bonjour,
Je suis en partie d'accord mais parmi les exemples donnés (dont notre OS de prédilection :-) ), certains ne semblent justement pas souffrir des "mêmes problèmes que la concurrence".
Ou alors on ne parle pas des mêmes problèmes.
C'est vrai qu'un certain nombre de projets sont parfois venus en "doublons" apparents de projets plus anciens avec la promesse de faire la même chose en mieux, plus simple et plus léger et au final pas si simple et si léger que ça (sendmail / postfix, apache / nginx…) mais souvent avec une approche et des fonctionnalités parfois légèrement différentes et attendues à un moment de l'histoire.
Oui, Python "batteries included", on peut juger que le nombre de "batteries" est insuffisant mais de base il y en a déjà plus que dans d'autres langages auquel il fût "opposé" (je dis ça sans méchanceté, venant du monde Perl qui est toujours un langage que j'utilise)
[^] # Re: Les derniers mètres sont les plus durs
Posté par HSimpson . Évalué à 3 (+2/-0).
Bien sur, tout ce que tu dis est vrai. Il y a encore plein de choses à faire (par ex le modèle de layout est encore en travaux), il y aurait des choses à redire (l’export html, me semble être typiquement la fausse bonne idée). J’ai des craintes concernant la séparation entre l’app et le binaire, j’espère qu’ils ne vont pas fermer tout ça une fois que ça aura vraiment pris (si ça prend vraiment).
Et non, on ne peut pas vraiment dire que typst reinvente la roue, étant donné les différences importantes d’approche et de modèle utilisé (même si je ne suis pas spécialiste du tout). Il a au moins l’intérêt d’essayer quelque chose de nouveau.
Ex : https://laurmaedje.github.io/posts/layout-models/
Sur le "procès" en recherche de la hype, ma seule défense est de dire que ça fait 25 ans que je suis exclusivement sous debian, dont une bonne partie en stable… ;-)
[^] # Re: Les derniers mètres sont les plus durs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7 (+4/-0).
Ça me semble sacrément difficile, mais une fausse bonne idée, je n'irais pas jusque là. Le PDF, c'est chouette pour publier des bouquins imprimés, mais de nos jours pas mal de gens lisent aussi sur téléphone, sur tablette, sur liseuse… Et le PDF, c'est carrément inadapté pour cela. Epub, ce serait déjà plus cohérent, et à la base c'est du HTML.
Bien sûr, il faut pour cela oublier toute idée de mise en page statique, et il se trouve que l'édition non visuelle est tout à fait appropriée pour cela. À condition justement de s'affranchir de toute volonté de rendu fixe, ce à quoi un éditeur avec visualisation en temps réel n'aide pas du tout.
[^] # Re: Les derniers mètres sont les plus durs
Posté par HSimpson . Évalué à 2 (+1/-0).
Je suis d’accord avec toi sur tout ce que tu dis, sauf que… il semble bien que le but soit de faire du rendu… Si ça sortait juste une belle structure qu’on va à côté mettre en forme grâce à la CSS qui va bien, là oui, bonne idée. Et encore, il faudrait prévoir pour chaque élément mis en forme dans le typ comment tu veux que ce soit représenté en html (attribut, élément…)… bref… pas convaincu (même si je suis sur que ça aurait une utilité, le surcout de travail ne me semble pas justifié).
[^] # Re: Les derniers mètres sont les plus durs
Posté par Sytoka Modon (site web personnel) . Évalué à 4 (+2/-0).
J'ai passé pas mal de temps pour passer des pages Wiki à des pages web avec deux contraintes, je voulais des pages web et un PDF. Web pour les utilisateurs, PDF afin d'avoir un document autonome que je puisse avoir sur mon PC ou donner facilement.
J'ai utilisé mkdocs pendant longtemps, mais impossible d'avoir une table des matière correcte dans un PDF (et puis chaque moteur a son langage Markdown). Au final, je suis parti sur du RST avec Sphinx qui mouline pas si mal HTML et PDF.
Clair, on est limité avec RST, bien plus qu'avec LaTeX. Cependant, on a une version Web de bonne qualité.
Bilan : un outil pour faire tout ? Est-ce faisable ? Sphinx et LaTeX utilise des tables globales pour les liens.
À mon sens, la bonne idée de TeX (LaTeX) est d'avoir en gros le caractère \ pour indiquer une commande quasi partout. Ainsi ce qui n'est pas texte est facilement identifiable. L'autre bonne idée est d'avoir le mode math dans lequel on bascule facilement. Mais mauvaise idée dans le mode tabular qui ne fonctionne pas bien pareil (par exemple les accents historiques).
Les bidouilles de __type__ **wiki**, cela va un temps, mais c'est vite le souk dès que ce sont des documents compliqués. D'ailleurs à ce niveau là, je préfère les doubles symboles __, **, ~~, `` et // aux autres solutions…
Ah, et autres contraintes que je rencontre souvent, avoir du français et de l'anglais. Le plus simple est souvent d'avoir les deux langues dans le même fichier (facilite la maintenance) mais il faut ensuite mouliner et par exemple garder le paragraphe de la langue si celui-ci existe et sinon prendre la langue qui reste pour ce paragraphe. Spip gère très bien cela (pour le Web) avec <multi>[fr]français [en]anglais</multi>. C'est hyper pratique et je n'ai pas vraiment retrouvé aussi souple ailleurs.
Tout cela pour dire que créer une interface pour gérer pas mal de cas d'usage n'est pas facile ;-)
[^] # Re: Les derniers mètres sont les plus durs
Posté par jch . Évalué à 8 (+7/-0). Dernière modification le 02 septembre 2025 à 12:56.
D'un autre côté, on a bientôt 50 ans d'expérience avec TeX, Knuth lui-même a fait plusieurs publications sur les problèmes qu'il n'avait pas résolus à l'époque, on peut donc espérer faire mieux.
D'un point de vue algorithmique, TeX a énormément fait avancer l'état de l'art. Cependant, les algorithmes utilisés ont des limitations, il est difficile par exemple de faire une mise en page de type journal (où un cadre déborde dans un autre cadre pas forcément contigu), et il est difficile de faire un texte qui contourne une figure (wrapfig est un hack, et qui ne marche qu'à moitié).
Du point de vue du langage d'entrée, TeX est basé sur les techniques de substitution (les macros), et on sait aujourd'hui que ce n'est pas une bonne fondation pour un langage de programmation. (D'où LuaTeX, qui permet d'écrire les paquets dans un langage de programmation basé sur des principes plus modernes.)
Il me semble difficile de résoudre ces limitations en préservant la compatibilité, et c'est depuis des années que je m'attends à ce que quelqu'un fasse un système de mise en page moins limité mais qui préserve tout ce qui est bon dans TeX. Très franchement, je ne suis pas sûr que Typst soit ce système, mais j'essaie de garder l'esprit ouvert.
[^] # Re: Les derniers mètres sont les plus durs
Posté par Computer (site web personnel) . Évalué à 5 (+5/-0).
Par conception il n'égalera jamais TeX.
TeX est un langage de macros qui met à disposition des primitives :
— de composition de documents très bas niveau (rien à voir en terme de souplesse de mise en page), en sortie dvi le moteur ne fait que manipuler des boîtes ;
— de modification TOTALE de sa syntaxe (le seul dans le monde informatique à le faire à ma connaissance) ;
— de programmation.
De plus :
— le moteur TeX historique supporte plutôt bien le utf8 dans les sources (y'a une combine et quelques limites pour les ligatures et le kerning), les lacunes viennent plutôt de la gestion des fontes en sorties, limitées à 256 caractères (127 sur la computer modern historique, d'où le bordel des encodages en sortie) et il faut donc basculer d'une fonte à l'autre, ce qui est fait de manière semi-automatisée en mode math ;
— les moteurs actuels comblent les lacunes à ce niveau-là (support opentype) ;
— la plupart des moteurs sont très rapide avec une installation minimale ;
— offre une stabilité à toute épreuve (je note que Typst ne prend aucun engagement à ce niveau-là) ;
— du fait de son âge est très optimisé, performant et rapide (dans une installation minimale).
Reste que le cœur historique est vieillot et que peu de monde est capable de le prendre en main. La syntaxe est certes absconse mais tout est parfaitement documenté et exempt de bug malgré la complexité du logiciel. Là déjà je suis tombé sur un bug gênant : pas d'alinéa pour un nouveau paragraphe lorsque le précédent se termine par une formule sur sa ligne. On joue pas du tout dans la même courre.
Un source plainTeX a une syntaxe extrêmement simple pour produire un document minimaliste. On peut concevoir une syntaxe très simple pour créer des documents un peu plus élaborés (le readme de mon "site web personnel" est un exemple, et je compile à moins de 10ms sur ma machine).
[^] # Re: Les derniers mètres sont les plus durs
Posté par steph1978 . Évalué à 3 (+1/-0).
Peut-on voir le résultat produit ?
Sur la forge:
[^] # Re: Les derniers mètres sont les plus durs
Posté par Computer (site web personnel) . Évalué à 2 (+2/-0).
https://forge.chapril.org/Nicolas/Retex/raw/commit/58fc998e1e3890c4d7ba1a9632c5d416839bfb53/readme.pdf
Quelques différences de rendu et de philosophie par rapport à LaTeX :
— pas de dimensions élastiques, donc les lignes sont proprement alignés de page en page (sauf la titraille qui va être décalée par rapport aux lignes de base, par esthétisme) ;
— pas de package (“dynamique”), mais des extensions, qui sont pré-compilés (“statique”), ici c’est mon format de base avec une extension verbatim (performance++, flexibilité-- : le format est prévu soit pour écrire des petits documents vite fait, soit pour des projets conséquents, devoir écrire l’extension qui va bien avec et donc mettre les mains dans le cambouis TeX) ;
— c’est le vrai moteur TeX vanilla qui a tourné (sans aucune extension, en réalité c’est rarement le cas sur une installation de base car on cherche quelques primitives supplémentaires…) et généré le dvi, puis passage par la moulinette dvipdfmx ;
— en conséquence pas de microtypographie (entre autres), mais c’est possible (j’ai testé avec pdftex et ça fonctionne, juste que ça représente pas mal de boulot…) ;
— le format travaille pour du français par défaut, et l’encodage utf8 ne couvre que les caractères français (limitation du moteur historique) ;
— les caractères utf8 dans le source, c’est fait exprès, c’est directement compris par le moteur (pour le fr/latin1 — ce sont les espaces insécables qui affolent le visionneur à priori), car je veux pouvoir saisir en bépo (y compris les maths : ∀𝑥 ∅⊂𝑥, car aucune commande LaTeX autorisée dans le source) ;
— un seul niveau de titraille non numéroté, c’est voulu, les gens qui se mettent à LaTex ont tendance à mettre trop de profondeur de titres, par contre j’ai un mécanisme qui permet de produire des alinéa et des paragraphes pour structurer le corps de texte sans mettre de titraille ;
— des documents plus élaborés doivent faire appel à des extensions (à écrire…) et ma philosophie sera de rester à un niveau de titraille par fichier, et la commande
\input fichier.texrajoute un niveau supplémentaire.[^] # Re: Les derniers mètres sont les plus durs
Posté par Colin Pitrat (site web personnel) . Évalué à 6 (+4/-0).
Le contre exemple évident est clang qui en apportant de la concurrence à gcc a fait un bien fou à tout le monde (y compris à gcc). Il se pourrait bien qu'il en soit de même ici.
[^] # Re: Les derniers mètres sont les plus durs
Posté par nojhan (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Mais oui ! Très bon contre-exemple, merci :-)
[^] # Re: Les derniers mètres sont les plus durs
Posté par steph1978 . Évalué à 3 (+2/-1). Dernière modification le 03 septembre 2025 à 18:14.
Je ne sais pas pour Tex/LaTeX/Typst mais pris de manière générale, cela veut dire qu'il ne faudrait jamais adresser un problème avec une nouvelle approche, qu'il faudrait toujours se résigner à améliorer l'existant. Alors déjà, c'est pas drôle, et le fun c'est important, mais surtout, on part de quoi exactement, on fige quoi ?
L'histoire (informatique) montre qu'en reprenant le problème, on peut produire une alternative qui rencontre son public.
Compliqué comme argument car tu ne compares à aucune référence. De ma compréhension de ta thèse, ces projets n'aurait rien apporté et aurait mieux fait de concentrer leur effort sur leur prédécesseur, c'est ça ? Reprenons :
Linux, versus les autres Unix ? il ne sont plus là pour témoigner (ou presque). Peut être que son seul apport est la GPL, peut être que c'est plus technique mais il a aujourd'hui tout écrasé.
Python, comme langage généraliste, versus quoi ? Perl/Pascal/Basic ? il est le plus apprécié des débutants, et permet de traiter une foultitude de problématiques avant de devoir aller chercher ailleurs.
Rust, versus C++ j'imagine ? Quand on voit la quantité de code produite en Rust et comme il est apprécié des développeur chevronnés, on doit pouvoir dire qu'il a apporté une très bonne réponse à la problématique de "memory safety vs perf".
Node … joker.
(celui-ce est de moi) Elixir, versus Erlang. La syntaxe de Ruby sur une plateforme d'une qualité exceptionnelle, avant réservée à une poignée d'ingénieur. Une merveille.
CMake, versus Make ? je connais pas assez pour dire.
Typst, versus LaTeX. Je ne suis pas le bon client car mes écrits peuvent se contenter de markdown mais si je devais produire un document de qualité "académique", je pense que je ferai plutôt l'effort de me lancer dans Typst que dans LaTeX. C'est tout à fait personnel.
Bref, le greenfield, souvent, ça fait du bien.
[^] # Re: Les derniers mètres sont les plus durs
Posté par jch . Évalué à 2 (+1/-0).
Et bien sûr TeX versus RUNOFF.
# Concurrence et orgmode
Posté par rick . Évalué à 5 (+5/-0).
Je trouve ça dommage de parler de concurrent, pourquoi ne pas utiliser le terme alternative ? Je ne suis ni un grand latexien ni un tysptien, mais il me semble que LaTeX soit bien plus configurable (pour l'instant) pendant que Typst vise la "simplicité" (entre guillemets, vu ce que ça peut déjà produire je suis vraiment impressionné). Les deux communautés peuvent passer d'un moteur à un autre, disons plutôt que l'écosystème évolue et s'agrandit !
Sinon sur un autre sujet, j'ai très hâte de voir un support natif de Tyspt pour orgmode. J'ai déjà vu un plugin mais il semble uniquement fait pour produire des exportations Typst. Rien pour du Typst à la volée, comme il y a actuellement pour LaTeX. Je vais suivre les listes de couriels de près :)
[^] # Re: Concurrence et orgmode
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
Comme termes, il me vient concurrent, successeur et alternative. Et tu as raison, alternative c'est plus neutre, alors que les autres sont orientés en ce sens qu'ils sont porteurs d'une notion de volonté spécifique.
Concurrent, ça évoque un marché et… une volonté de concurrence entre plusieurs solutions.
Successeur, ça évoque carrément une volonté de supplanter une autre solution. Et ça pour le coup, je pense que les développeurs de Typst n'en ont pas spécialement l'intention. Se développer, oui, que ce soit en partie au détriment de l'usage de LaTeX, sûrement mais ce n'est pas un but en soi. :-)
[^] # Re: Concurrence et orgmode
Posté par rick . Évalué à 1 (+1/-0).
En effet, je trouve que alternative, en plus d'être "plus" neutre, retire l'aspect concurrence, trop mis en avant :(
Je n'avais pas pensé au terme successeur, je trouve ton analyse très juste :)
# Applis Typst
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 10 (+9/-1).
J'ai récemment commis un mémoire de master que j'ai rédigé avec Zettlr, me disant que je pourrais apprendre à l'exporter en LaTeX sur le tas. En fin de compte, j'ai pas compris comment ça marchait et j'ai exporté en ODT que j'ai restylé dans LibreOffice, mais je reste séduit par l'idée du What you see is what you mean qui gouverne l'édition en LaTeX, Typst, Markdown et autres techniques web2print.
Du coup, je surveille du coin de l'œil cette nouvelle application en libadwaita, Typewriter, qui semble bien partie pour faire exactement ce que je voulais faire avec mon mémoire (la gestion de Zotero en moins). Je viens d'essayer de créer un projet dedans : ça m'a proposé un paquet de templates sympas. Je pourrais probablement en proposer un à ma fac pour que les étudiant⋅e⋅s puissent faire leurs travaux avec.
[^] # Re: Applis Typst
Posté par lejocelyn (site web personnel) . Évalué à 6 (+4/-0).
Est-ce que tu aurais une copie de cette thèse de doctorat ? elle m'intéresse beaucoup !
[^] # Re: Applis Typst
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Tu peux la télécharger directement depuis l'appli !
Sinon, elle se trouve ici : https://typst.app/universe/package/paris-saclay-thesis-flat/
# belle progression !
Posté par qpad . Évalué à 2 (+1/-0).
Hello,
Merci pour cette dépèche !
Je suis agréablement surpris par la belle évolution de typst ces dernières années.
Et je suis aussi assez conforté dans ma bonne impression après avoir rédigé quelques document en typst. Dur de retrourner à LaTeX après…
Il me manque encore au moins 2 fonctionnalités avec typst:
- un équivalent de git-latexdiff
- un moyen de naviguer entre le document pdf ouvert dans une appli de bureau (ex: evince) et le document source dans un éditeur classique (ex: emacs ;P)…
Mais vu le dynamisme actuel autour du projet, il y'a de l'espoir que celles ci arrivent vite!
[^] # Re: belle progression !
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 04 septembre 2025 à 11:20.
La seconde fonctionnalité s'appelle SyncTeX. Il manque donc un SyncTypst. :-)
Je ne connais pas la spec SyncTeX mais je ne serais pas surpris que ce soit presque directement utilisable pour d'autres langages. Et qu'il s'agisse donc surtout pour Typst d'implémenter SyncTeX.
[^] # Re: belle progression !
Posté par rahan . Évalué à 2 (+1/-0).
Cette fonctionnalité existe avec l'extension
Tinymist typstde VS Code. Ça marche très bien.Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.