Obtenir le pack de test sur GitHub
Sélectionnez Code → Download ZIP pour garder ensemble le document et les fichiers image. Le dépôt permet aussi d’examiner la source et de consulter les modifications avant le téléchargement.
Le pack est publié sous la licence ouverte CC BY 4.0. Vous pouvez réutiliser ou adapter le contenu de test en citant la source. Cela ne fait pas de l’application Markdific un logiciel open source.
Réponse rapide : téléchargez le ZIP, ouvrez le même fichier
.mddans chaque outil, notez ce qui s’affiche correctement, puis enregistrez et exportez une copie de travail. Consignez séparément le rendu, les allers-retours Markdown et les formats exportés.
Ce que couvre le test
Le document en version 1.0 compte 30 sections numérotées. Chaque section indique si elle teste CommonMark, le GitHub Flavored Markdown (GFM), une extension courante, une syntaxe propre à une application, le comportement HTML ou un aller-retour.
| Domaine | Exemples | Ce qu’il faut vérifier |
|---|---|---|
| CommonMark | Titres, liens, listes, citations, code, sauts de ligne | Analyse et structure du document |
| GFM | Tableaux, listes de tâches, texte barré, liens automatiques | Prise en charge de la syntaxe étendue |
| Images | PNG, JPEG, WebP, noms de fichiers avec espaces, images distantes | Chargement et conservation des chemins |
| Contenu technique | Formules LaTeX et sept types de diagrammes Mermaid | Aperçu, repli sur la source, export |
| Syntaxe propre à une application | Wiki-links, intégrations, callouts et tags Obsidian | Portabilité et récupérabilité |
| Allers-retours | Ouvrir, modifier, enregistrer et exporter | Réécritures de la source et contenu perdu |
Les formules, Mermaid et la syntaxe Obsidian ne font pas partie du cœur de CommonMark. Un outil peut être un moteur de rendu CommonMark fidèle sans les prendre en charge. Le pack est un document de comparaison pratique, pas une suite formelle de conformité aux normes.
Comment mener une comparaison équitable
- Téléchargez le ZIP du dépôt. Décompressez-le sans séparer le document
.mddu dossierassets/. - Gardez une copie de référence intacte. Notez la version de l’application, le système d’exploitation, le mode de rendu et la date du test.
- Ouvrez une copie de travail dans le premier outil. Vérifiez le rendu et, si possible, la source.
- Faites une petite modification, enregistrez en Markdown et comparez le fichier enregistré avec la copie de référence.
- Exportez vers chaque format proposé par l’outil, comme HTML, PDF ou DOCX. Ouvrez l’export et examinez-le séparément.
- Recommencez avec la même copie de référence dans les autres outils. Remplissez le tableau de résultats inclus dans le document.
Ne réduisez pas toutes les observations à une seule note « prend en charge le Markdown ». Un visualiseur peut afficher un diagramme sans permettre de le modifier. Un convertisseur peut conserver son apparence dans le PDF mais perdre la source Mermaid. Ce sont des résultats différents.
Libellés de résultat
- Réussi : la structure et le sens sont préservés après l’opération testée.
- Partiel : le contenu reste utilisable, mais la mise en forme, la source, les métadonnées ou la possibilité de modification changent.
- Non pris en charge : une extension de syntaxe facultative n’est pas implémentée, mais la source reste récupérable.
- Échec : le contenu disparaît, devient trompeur, exécute du contenu dangereux ou ne peut pas être récupéré.
- Non testé : l’opération n’a pas pu être effectuée ou ne s’applique pas.
Notez les éléments qui justifient chaque libellé. Par exemple, « Mermaid affiché sous forme de bloc de code lisible » relève généralement de Non pris en charge, et non d’Échec, sauf si l’outil annonce le rendu Mermaid.
Tests d’images : ce qui doit et ne doit pas se charger
Le ZIP contient six images de test locales fonctionnelles : PNG, JPEG, WebP, un nom de fichier avec espaces, une image référencée en HTML et une image collée à la manière d’Obsidian. Gardez le dossier assets/ à côté du document. Les six fichiers utilisent volontairement le même visuel simple, pour que la comparaison porte sur le format de fichier et la gestion des chemins, et non sur des différences visuelles sans rapport.
Deux autres chemins ne sont volontairement pas résolus dans le pack autonome. Un chemin relatif au dossier parent dépend d’une arborescence plus large, et un chemin relatif à la racine d’un site dépend d’un site web. L’image distante dépend de l’accès au réseau. Ces cas testent la façon dont un outil signale les ressources manquantes ou externes ; il ne s’agit pas de fichiers absents du ZIP.
Si toutes les images locales fournies échouent, vérifiez d’abord la décompression, l’emplacement des dossiers et les autorisations des fichiers locaux avant d’évaluer le moteur de rendu.
Que vérifier après l’enregistrement et l’export
Un aperçu visuel peut masquer des changements dans la source. Vérifiez si le Markdown enregistré présente des destinations de liens perdues, des chemins d’images réécrits, des tableaux cassés, des délimiteurs de code modifiés, des caractères échappés ou des métadonnées supprimées. Une normalisation de mise en forme sans conséquence n’est pas une perte de sens.
Pour le PDF, examinez les sauts de page, le retour à la ligne du code, les formules, la résolution des diagrammes et les liens. Pour le DOCX, vérifiez si les titres, les tableaux, les listes et les images restent modifiables. Pour le HTML, vérifiez la structure, les ressources locales et le traitement sûr du HTML brut.
Le document contient un test de script inoffensif. Un aperçu sécurisé peut l’échapper, le supprimer ou afficher la source sans l’exécuter. Ne considérez pas le blocage de l’exécution du script comme un échec.
Partager des résultats reproductibles
Quand vous publiez une comparaison, indiquez la version du pack (1.0), l’outil et sa version, le système d’exploitation, la configuration, la méthode d’import, les réglages d’export, le tableau de résultats rempli et des captures d’écran des différences significatives. Signalez toute modification du fichier de test.
Markdific a créé le pack et peut figurer parmi les applications testées. Appliquez le même fichier et les mêmes définitions de notation à chaque application. Ne considérez pas l’absence d’une fonctionnalité facultative comme un défaut au seul motif qu’un produit la propose.
Téléchargement et réutilisation
Ouvrir le Markdown Compatibility Test Pack sur GitHub
Utilisez Code → Download ZIP pour obtenir ensemble le document .md, le dossier assets/, le README et la licence.
Le document et les images de test fournies sont sous licence CC BY 4.0. Citez « Markdific Markdown Compatibility Test Pack v1.0 », ajoutez un lien vers le dépôt et la licence, et signalez les modifications si vous adaptez le contenu.
Questions fréquentes
S’agit-il d’une suite de tests CommonMark officielle ?
Non. CommonMark a sa propre spécification et ses propres exemples de conformité. Ce pack teste des documents et des usages concrets, y compris les extensions et l’export.
Puis-je tester un générateur de sites statiques ?
Oui. Notez le moteur, les plugins, la configuration, le thème, la version de build et les règles de chemin des ressources. Comparez le HTML et les fichiers générés, pas seulement l’aperçu de développement.
Puis-je publier ou modifier le pack de test ?
Oui, selon la licence CC BY 4.0. Citez la source, ajoutez un lien vers la licence et indiquez les modifications. Conservez l’identifiant de version d’origine dans les résultats de comparaison pour que les lecteurs sachent ce qui a été testé.