- Un système typographique moderne qui étend la syntaxe Markdown existante pour permettre de créer facilement des documents dans divers formats, notamment livres, articles scientifiques, slides et présentations
- Intègre directement dans le Markdown des fonctions avancées comme la prise en charge des fonctions, l’utilisation de variables, les conditions/boucles et une bibliothèque standard, ce qui le distingue du Markdown classique ou de LaTeX par sa capacité d’extension et d’automatisation
- À partir d’un seul fichier source, il est possible de générer plusieurs sorties comme HTML, PDF, slides (RevealJS) et livres paginés (paged.js), avec une spécialisation pour la création de contenus orientés code
- Grâce à des fonctions de scripting et à une syntaxe d’extension expressive, il permet aussi de réaliser librement des contenus complexes ou dynamiques
- Fournit un environnement avec REPL, aperçu en direct et compilation rapide, permettant l’édition et le débogage de documents en temps réel
- Par rapport aux outils existants, il se distingue par ses fonctions de scripting, le contrôle du document et une courbe d’apprentissage accessible, avec des avantages face à Markdown, LaTeX, Typst, AsciiDoc et MDX
- Sans environnement de développement séparé ni configuration complexe, il fonctionne sur les principaux systèmes d’exploitation avec Java 17 ou version ultérieure uniquement
About
- Quarkdown est un système de composition moderne conçu pour ajouter des fonctions et une syntaxe étendue à la structure de base du Markdown, afin de permettre aux utilisateurs de produire facilement des résultats aboutis dans des formats variés, du simple texte aux livres, articles scientifiques et slides
- Il est développé sur la base de CommonMark et GFM, et prend en charge sa propre syntaxe, ainsi que les fonctions, variables et même les bibliothèques définies par l’utilisateur
- Il propose une syntaxe propriétaire appelée Quarkdown Flavor
- Une syntaxe d’extension fonctionnelle Turing-complète ajoute au Markdown des fonctions avancées comme les fonctions, conditions et boucles
- Les bibliothèques .qmd permettent d’utiliser diverses fonctionnalités comme la mise en page, les entrées/sorties, les mathématiques, les conditions et les boucles
- Même dans les cas où une structure documentaire complexe ou un contenu dynamique est nécessaire, il permet d’améliorer l’extensibilité et la productivité
Principales caractéristiques et usages
- Prise en charge de nombreux formats de sortie, dont HTML, slides, livres (Paged) et PDF
- Le type de document peut être défini par des appels de fonction comme
.doctype {slides} ou .doctype {paged}
- Intégration avec des moteurs open source comme reveal.js et paged.js
- Scripting et contenu dynamique
- Introduction d’éléments de programmation tels que fonctions, variables, conditions et boucles
- ex.)
.function {greet} ... .greet {world} from:{iamgio}
- Aperçu en direct et compilation rapide
- Fournit un aperçu en temps réel et une fonction de surveillance des modifications de fichiers (Watch)
- Les options
-p --preview et -w --watch améliorent l’efficacité du travail
- Comparaison avec d’autres outils documentaires
- Courbe d’apprentissage plus faible que LaTeX et extensibilité fonctionnelle supérieure à Markdown
- Montre aussi des points forts en scripting et expressivité face à Typst, AsciiDoc et MDX
Cibles prises en charge
- HTML
- Sortie standard (par défaut)
- Slides (avec reveal.js)
- Format livre/article scientifique (avec paged.js, serveur web requis)
- PDF
- Tous les types de documents et fonctionnalités pris en charge en HTML peuvent être exportés tels quels en PDF
- Pour plus de détails sur la sortie PDF, voir la documentation du wiki
- Le format de sortie peut être contrôlé par des appels de fonction comme
.doctype {slides} et .doctype {paged}
Comparaison
|
Quarkdown |
Markdown |
LaTeX |
Typst |
AsciiDoc |
MDX |
| Concision et lisibilité |
✔ |
✔ |
✗ |
✔ |
✔ |
✔ |
| Contrôle complet du document |
✔ |
✗ |
✔ |
✔ |
✗ |
✗ |
| Fonctions de scripting |
✔ |
✗ |
prise en charge partielle |
✔ |
✗ |
✔ |
| Sortie au format livre/article |
✔ |
✗ |
✔ |
✔ |
✔ |
3rd party |
| Sortie présentation |
✔ |
✗ |
✔ |
✔ |
✔ |
3rd party |
| Courbe d’apprentissage |
verte |
verte |
rouge |
orange |
verte |
verte |
| Cibles prises en charge |
HTML, PDF |
HTML |
PDF, PostScript |
PDF |
HTML, PDF, ePub |
HTML |
5 commentaires
C’est peut-être à cause du tableau que la mise en page mobile est cassée.
En donnant
min-width: 0à.topic_contents, le problème se corrige.min-width, quelle galère...Ah, j’ai résolu le problème d’une autre manière. Merci !
Merci pour ce retour rapide~
Commentaires sur Hacker News
Mon éditeur de texte FOSS, KeenWrite, utilise une approche similaire pour convertir le Markdown en XHTML, TeX et PDF
L’architecture logicielle montre comment concevoir une chaîne de processeurs
J’ai créé KeenWrite pour pouvoir utiliser des variables comme les noms de personnages ou de lieux quand j’écris de la science-fiction
Voir le tutoriel pour plus de détails
Pour ceux qui utilisent encore pandoc et des scripts shell, la série Typesetting Markdown explique comment construire une infrastructure de scripts pour convertir du Markdown en PDF
Plus d’infos sur KeenWrite ici
Le schéma d’architecture est visible ici
Il serait intéressant de comparer ce projet à Typst, qui a récemment beaucoup attiré l’attention, donc je suis surpris que Typst ne soit pas du tout mentionné dans la matrice de comparaison des fonctionnalités
Globalement, les deux projets semblent très similaires
Je me demande si le tableau comparatif est exact – lien
Il me semble que LaTeX a clairement des capacités de scripting complètes, même si c’est pénible à utiliser
Je reste sceptique face à l’idée que la syntaxe ésotérique de Quarkdown soit plus concise et lisible que celle de Typst
Je ne pense pas non plus que la courbe d’apprentissage soit plus facile que Typst, les deux me paraissent assez proches
Il me semble aussi que LaTeX peut produire du HTML avec tex4ht
La barrière à l’entrée ne peut guère être plus basse
Bien sûr, la courbe d’apprentissage n’est pas exactement la même chose que la barrière à l’entrée, mais les deux se recoupent largement
Et la « courbe d’apprentissage » est une caractéristique subjective
Si on l’ajoute dans un tableau comparatif, il sera forcément biaisé dès le départ
Les fonctionnalités explicites sont plus objectives, même si selon le produit certaines peuvent ne pas être nécessaires
Le tableau comparatif est manifestement inexact
Les exemples de sortie ont l’air super
Mais je n’aime jamais vraiment quand un langage de template grossit avec des appels de fonctions et de la complexité
Bien sûr, dans ce contexte ça a peut-être du sens
Mais si on doit l’utiliser avec un autre langage, par exemple pour du rendu côté serveur ou de la génération de documents pilotée par des données, on finit par perdre beaucoup trop de temps à naviguer entre les deux
Un langage de template n’est jamais aussi puissant qu’un « vrai » langage
C’est pour ça que je préfère des approches comme JSX ou les tagged template literals de JavaScript
Utiliser un vrai langage de programmation tout en comprenant le contexte du document, de manière à moins se soucier des échappements (comme pour les XSS), me paraît préférable
Je me demande en quoi ce projet diffère de Quarto
Le nom est similaire, l’extension aussi, et l’orientation semble proche, mais les fonctionnalités ont même l’air plus limitées – Quarto
La FAQ indique qu’il est développé par les mêmes personnes
Il y a quelques jours, un ami m’a montré qu’il réécrivait tous ses scripts de cours en Quarto, avec même des présentations intégrées, et ça avait l’air plutôt propre
Le fait que Quarto s’intègre bien avec R Studio et Jupyter Notebook est un gros avantage
Je pense que c’est une forme d’évolution convergente
Je trouve intéressant que ce qui peut ressembler à une « planète » soit en fait un quark, plus précisément un quark down
Projet cool, mais comme QuarkXPress est une marque bien connue dans l’édition, utiliser le mot « Quark » pour un système de publication est un peu risqué
Les dépôts de marque associés sont visibles ici et ici
(Je me demande aussi pourquoi le même mot fait l’objet de deux dépôts distincts)
Dans chaque thread de discussion sur ce sujet, il y a toujours 70 % de commentaires du genre « pourquoi ne pas utiliser LaTeX ? », donc je vais être clair d’emblée
Oui, j’ai clairement besoin d’un système de composition moderne basé sur Markdown
J’aimerais qu’il y ait plusieurs tentatives pour remplacer LaTeX
LaTeX est vraiment peu pratique et daté, et j’aimerais un système qui permette un balisage plus libre
Même si, à mesure que les fonctionnalités s’enrichissent, la syntaxe devient plus longue, il y a clairement besoin d’un espace un peu plus puissant que Markdown
Mais j’ai l’impression que ce projet n’est pas ce que je cherchais
En voyant les exemples, ça semble simplement pencher vers quelque chose d’un peu plus puissant que Markdown, sans vraiment être un remplaçant complet de LaTeX (ou de Typst)
Ce genre de système documentaire doit être « vraiment fluide » à utiliser, et celui-ci ne donne pas cette impression
Ce n’est pas idéal pour sa diffusion
J’aimerais que ce soit compatible au maximum avec le Markdown normal, mais si l’indentation des arguments de fonction est obligatoire, on a l’impression que tout le document va finir indenté, alors qu’en pratique les points d’extension de Markdown sont généralement plus naturels sous forme de blocs de code (du type ```plugin-name`)
À cause des différences de syntaxe, il faudra peut-être restructurer tout le document
Si on rédige dès le départ dans un but de publication, on peut tout aussi bien travailler directement en LaTeX
Là où c’est le plus utile, c’est quand c’est bien intégré dans une application de prise de notes
Certains le font peut-être dans Emacs ou Vim, mais même moi qui suis plutôt old school, je dois admettre que je suis finalement passé à Obsidian et compagnie
Ce serait bien d’avoir une partie qui permette de mieux contrôler la structure du document depuis l’app de notes, voire de relier aussi des fonctions de publication
Si c’est un outil autonome, je me demande pourquoi je l’utiliserais
Au moins, Typst a un éditeur en ligne, et c’est ce que tout le monde utilise
L’essentiel est justement de ne pas ajouter de choses inutiles dans un document
Ces systèmes (Typst inclus) sont fondamentalement conçus pour la composition de longs textes comme les articles universitaires
J’aimerais qu’ils deviennent une alternative à HTML, mais même après avoir essayé Typst, j’ai l’impression que leurs auteurs ne se préoccupent presque que des « articles ou longs textes »
J’aimerais aussi pouvoir créer des formulaires, des factures, des flyers, des cartes de visite, mais ce genre d’éléments ne semble pas les intéresser
(En réalité, je pensais à Sile, mais Typst est similaire)
Je n’ai pas beaucoup utilisé Typst parce qu’il est commercial
Surtout que les formulaires interactifs sont déjà en cours de développement (le backend du writer PDF en prend déjà partiellement en charge certains aspects)
Avec un peu de temps, les fonctionnalités de formulaire devraient arriver dans Typst – voir cette issue
Les factures, prospectus, cartes de visite, etc. exigent souvent de placer précisément de petits éléments au centre de la page ou le long des bords, et pour cela les outils WYSIWYG sont plus pratiques
Avec une composition purement textuelle, on passe par trop d’essais-erreurs
Par exemple, dans un tabloïd, le texte doit parfois s’écouler et s’enrouler autour d’images ou de découpes plutôt que dans un simple rectangle, et faire ça uniquement avec des coordonnées sans le voir à l’écran est très difficile
Je l’installe avec cargo en Rust et je l’utilise très bien sans l’éditeur en ligne
C’est assez simple pour créer plusieurs types de documents
Je l’utilise déjà comme alternative pour produire des slides et des handouts
Il manque encore quelques fonctionnalités comme l’habillage d’image ou le flux de texte, mais c’est aussi difficile dans TeX, et c’est prévu plus tard dans Typst
Exemple d’affiche
Ça ressemble quasiment à du reStructuredText (rST)
La syntaxe de fonction de Quarkdown (
.somefunction {argument} {argument} body) et celle de rST (.. somefunction:: {argument} {argument} body) se ressemblent beaucoupIl y a tellement de Markdown, Quarkdown, Typst, etc., et si peu de standardisation, que je finis par revenir à HTML+CSS
Je ne l’ai pas utilisé directement, mais j’y réfléchis assez sérieusement
Les autres formats sont complexes et ont une courbe d’apprentissage qui finit par gêner l’écriture elle-même
Avec XML, je peux définir librement mes propres balises et construire diverses structures avec un parseur, comme la génération automatique de notes de bas de page
Je me demande si quelqu’un a déjà adopté cette approche
Le problème arrive quand trop de gens empilent des systèmes par-dessus et essaient ainsi de résoudre quelque chose de « plus complexe »
J’ai l’impression qu’ils prétendent améliorer un système conçu à l’origine pour un usage simple, sans en comprendre les limites, et qu’au final ils ne font qu’ajouter de la répétition inutile et de la confusion
Ce n’est pas un manque de fonctionnalités, c’est un problème de dépassement du périmètre pour lequel il a été conçu
Même si on ajoutait de la mise en forme au bloc-notes Windows, je ne considérerais pas ça comme une amélioration au fond
Le bloc-notes avait déjà son rôle propre
Si Emacs ne vous rebute pas, c’est un bon choix
Pas besoin de mémoriser des centaines de frameworks et de syntaxes compliquées
Demander à une IA de générer un convertisseur markdown vers html fait très bien l’affaire
Dans The Art of Unix Programming, publié en 2003, on trouve déjà l’idée que l’édition directe de XML est pénible et qu’il fallait donc créer toutes sortes de formats et de parseurs nouveaux