ZEP-05 : Refonte du traitement markdown pour l'export

Une Zep un peu particulière peut être car le besoin est assez évident et ne fait pas trop de doute mais il faut une discussion pour décider des choix techniques et du processus qui sera utilisé pour l'améliorer.

Problématique et situation actuelle

Le back-end peut actuellement, à partir des sources markdown, produire trois type de sorties :

• du html, pour l'affichage en ligne
• du pdf pour impression et consultation hors-ligne
• du epub pour lecture sur liseuse et consultation hors-ligne

Le html est généré par Python-zMarkdown, un fork de Python-Markdown principalement constitué d'extensions permettant de supporter nos ajouts de syntaxe. Les deux autres formats sont produit via Pandoc après le passage des sources dans quelques scripts pour les formater a peu pret convenablement pour Pandoc. Principalement ces codes vont, à coup de regex :

• Décaler les titres pour insérer ceux du cours et des chapitres,
• Tout concaténer,
• Télécharger les images et remplacer le contenu de celles-ci pour qu'elles soit dispo en local et incorporable par latex,
• etc.

Comme vous pouvez le remarquer, ce passage fonctionne mais de manière limité. Le rendu est loin d’être parfait et certaines de nos extensions ne sont pas supportés. De plus par sa nature limité, les remplacements automatiques peuvent entraîner des problèmes de transformations car ils ne disposent pas de l'arbre syntaxique complet au moment de la transformation.

Cette Zep cherche donc a trouver un solution permettant de rationaliser ces transformations et corriger les problèmes du rendu actuel.

Le code actuel a ce processus :

1
2
3
4
5

Source markdown -+-[  parser ]--> Arbre syntaxique 1 (AST) --[Generation]--+-> Html
                 | [zmarkdown]
                 | 
                 +-[parser]--> Arbre syntaxique 2 (AST) --[Generation]--+-> (Latex) -> Pdf
                   [pandoc]                                             +-> epub

Solution idéal

Un solution idéal serait qu'un logiciel comprend entièrement notre syntaxe et se charge de produire les trois types de sorties. Disposant de sa représentation interne, il pourrait en une seule passe, si demandé, produire directement les 3 sorties (évitant de parser plusieurs fois l'entrée) ou simplement le html (pour le forum ou pour les périodes de rédactions).

Le processus de traitement minimal serait alors le suivant :

1
2
3

Source markdown --[parser]--> Arbre syntaxique (AST) --[Generation]--+-> Html
                                                                     +-> (Latex) -> Pdf
                                                                     +-> epub

Solutions retenu :

Utiliser Pandoc pour la chaine entière

Au lieu de transformer le zMarkdown pour faire le taf actuel de Pandoc on peut envisager le chemin inverse et chercher à étendre Pandoc pour supporter nos extensions

Avantages :

• Arriver à la solution idéal
• Maîtrise total de la chaîne
• Augmentation des formats de sorties possibles

Désavantages :

• Pas mal de dev pour porter dans Pandoc toutes nos modifs
• Nécessite des ressources de dev en Haskell rare et dont nous ne disposons pas dans l'équipe.
• Changement de parseur donc des changements de comportements sont à prévoir qui devront être cernés et peut être nécessiter des scripts de migrations spécifiques

Autres solutions non retenu

Solutions possibles

Je vais lister toutes les solutions envisageable. Toutes les solutions vont être rapportées ici. Les différents avis de la communauté seront rapporté pour permettre le choix.

Production des sorties depuis zMarkdown

Une première évolution possible, puisque Python-zMarkdown sait déjà interpréter toute notre syntaxe et produire un arbre syntaxique correspondant serait de lui rajouter les modules de générations Latex et epub.

Avantages :

• Arriver à la solution idéal
• Maîtrise total de la chaîne
• On reste sur du 100% Python

Désavantages :

• La structure actuelle de Python-zMarkdown est celle de Python-Markdown et est pensé pour produire du html (ou xhtml), pas autre chose. L'AST est donc en fait un arbre type XML (ElementTree) qu'il est parfois pénible de parcourir pour autre chose que le html.
• Nécessité de créer et maintenir plusieurs modules d'exports en plus du parseur (temps de dev, mise au point et maintenance important).

Production depuis zMarkdown en sorties de markdown-pandoc

En version intermédiaire à la précédente, pour simplifier le travail ou faire un jalon plus rapidement atteignable à moyen terme, une solution serait de faire produire un markdown "compatible pandoc" au zMarkdown. Ainsi on pourrait assurer la qualité de sortie tout en gardant globalement la chaine courante. On arriverai à quelque chose comme :

1
2
3

Source markdown --[zmarkdown]--+-> Html
                               +-> Markdown-pandoc --[Pandoc]--+-> (Latex) -> Pdf
                                                               +-> epub

Avantages :

• Conservation des outils existants
• On reste sur du 100% Python
• Assez rapide à développer vis a vis de la solution précédente

Désavantages :

• Étapes de transformations successives inutiles.
• Nécessité de générer un "markdown-pandoc" spécifique à chaque sortie (même si une grosse partie serait commune).
• La structure actuelle de Python-zMarkdown est celle de Python-Markdown et est pensé pour produire du html (ou xhtml), pas autre chose (voir solution au dessus).

Passer par un module de production de contenu spécifique en Python depuis zMarkdown

Une solution proche de la première et limitant ces inconvénients serait d'utiliser un module existant qui permet, en python, de produire les différentes sorties à partir d'une description du document. Concernant notre processus, l'idée serait de se baser sur un module externe pour le bloc "génération"

Avantages :

• Arriver à la solution idéal, possibilité de le faire par étape (dans un premier temps faire la conversion "AST actuel" -> "Modèle de données du module" puis refaire le contenu de python-zmarkdown pour produire directement le modèle de document du module de sortie)
• Limitation de la maintenance à la partie parseur
• On reste sur du 100% Python

Désavantages :

• Il faut trouver un package qui correspond à nos besoins

Utiliser des transformation XSLT pour produire les sorties depuis zMarkdown

Le zMarkdown peut produire son arbre syntaxique sous forme de XML (en réalité une sorte de HTML5 en XML). Il est donc possible de le transformer vers n'importe quel format avec des XSLT.

Avantages :

• Presque la solution idéal (on passe juste par un format intermédiaire)
• Extensible facilement à d'autres langages
• Technologie assez courante

Désavantages :

• On a pas de ressources de dev actuellement sur ces technos
• Peut prendre du temps à mettre en place

Utiliser un autre parseur qui résout déjà une grosse partie de ces problématiques

Il n'y a pas que ces deux modules qui existent, beaucoup d'autres parseurs existent dont probablement certains répondant à tous nos besoins

Avantages :

• Arriver à la solution idéal
• Maîtrise total de la chaîne

Désavantages :

• Pas mal de dev pour porter toutes nos modifs.
• Choix du module complexe, long tests et études à prévoir.
• Changement de parseur donc des changements de comportements sont à prévoir qui devront être cernés et peut être nécessiter des scripts de migrations spécifiques.

Créer un convertisseur dédié

Refaire un parseur markdown dédié a notre site et nos problématiques.

Avantages :

• Arriver à la solution idéal
• Maîtrise total de la chaîne

Désavantages :

• Beaucoup de dev
• Choix techniques complexes, long tests et études à prévoir.
• Changement de parseur donc des changements de comportements sont à prévoir qui devront être cernés et peut être nécessiter des scripts de migrations spécifiques.

Conclusion

En cours de dev. Toute aide est la bienvenue.

Oo quelle ZEP … je l'ai lu en diagonale, mais il me semble qu'il faut bien prendre en compte ce paramètres dans les choix de décision.

Lors de la reconstitution du markdown final pret à la génration pdf, tous les titres sont décalés selon qu'on soit dans un big ou un mini tuto. Ce décalage de titre actuellement n'est pas pleinement fonctionnel car il agit aussi dans les balise code car on ne dispose pas de l'AST à ce moment là.

Pour le reste, je lirai plus attentivement plsu tard.

Oui c'est pour ça que je n'ai mit que des solutions qui supposait que les vrais traitements étaient fait sur des AST, quitte à parser du contenu deux fois de suite en passant par des formats intermédiaires

Personnellement, je suis plutôt attiré par la solution on fait un pandoc avec XML puis ensuite on balance du XSLT. Cela a deux avantages :

• la transformation peut se faire côté client quand on est sur le forum, ce qui limite beaucoup le travail du serveur, et surtout cela facilitera énormément la création de nouveaux themes.
• si on n'y va qu'en latex/pandoc c'est vite fastidieux d'améliorer les PDF. J'en avais parlé lors d'une béta privée : un PDF ayant pour but d'être imprimé ne peut pas afficher de liens, qu'il faut remplacer par des notes/index. Avec pandoc ça demanderait une connaissance pointue. Avec XSLT, ça demande une heure de dev pour transformer les <a href... en mot normal + petit nombre + index en fin de doc.

un PDF ayant pour but d'être imprimé ne peut pas afficher de liens, qu'il faut remplacer par des notes/index. Avec pandoc ça demanderait une connaissance pointue

Euh, je crois que la charge de travail est la même pour une connaissance équivalente des deux technologies (pandoc vs XSLT).

Si tu souhaite ne pas afficher les liens via pandoc par exemple, il suffit avant de lui passer ton texte de virer le contenu la partie url. En gros, remplacer en amont tous les [label](url) par label.

Donc, je ne crois pas que ce soit vraiment un argument.

Je n'ai rien contre cette solution si on trouve un dev pour s'en occuper. Perso j'ai jamais touché à ça donc je ne me sent pas de me lancer là dedans.

@firm1 : Non ce n'est pas exactement pareil. Dans le cadre d'une transformation XSLT tu as en gros un fichier xml qui est en réalité une sérialisation de l'AST. Un transformation XSLT peut être vu alors comme une règle de génération, permettant de passer d'une AST à un fichier de sortie. Tu n'auras pas du tout les mêmes problèmes que toi car dans ce XML les balises sont déjà interprété. Du coup les images sont des feuilles de type image, le même code est aussi tel quel dans une feuille de type code si c'est un extrait. Bref non je pense que ça peut etre une solution propre. Malheureusement il nous faudrait quelqu'un pour s'en occuper. C'est exactement le même problème que d'étendre Pandoc : Ce n'est pas que la solution technique est mauvaise mais qu'on a pas les ressources humaine pour ça.

@Kje : je réagissais juste au message qui disais ceci :

En répondant que pour ce cas spécifique, la difficulté est quasi inexistante.

Par contre pour le workflow complet, c'est autre chose. Je n'ai pas encore pris le temps de lire dans le détails les solutions énnoncées.

Plus je vois cette phrase (« on n'a pas de gens qui ont les compétences pour faire ça a priori »), plus je me dis que ça ne nous empêche pas d'essayer. Concrètement, à partir du moment où nous définissons ce que nous voulons, pourquoi ne pas envisager une sorte "d'atelier R&D" ?

Il suffirait de regrouper des personnes motivées pour tenter l'expérience et de lancer le mini-projet sans se coller la pression.

L'expérience pourrait être sympa, il existe des sites (je pense bien sûr à PdP) sur lesquels on peut trouver des réponses à nos questions, et si on prend la peine de documenter nos efforts, ça pourrait éventuellement s'avérer enrichissant, aussi bien pour notre culture personnelle que pour la communauté.

Mon raisonnement, au fond, est le suivant : nous sommes sur un site à vocation pédagogique, pourquoi ne pas pousser l'apprentissage jusque dans le développement de ce genre de choses un peu pointues ? Ça ne nous engage à rien (aucune obligation d'adopter le truc en prod), si ça réussit on y est tous gagnants, et même si ça n'aboutit pas on aura des leçons à en tirer.

Je ne dit pas le contraire et c'est bien pour cela que j'ai listé toutes ces solutions. Une réponse à ces désavantages peut être simplement "Formons nous". Pour le moment je n'ai fait que lister toutes les possibilités les plus évidentes au problème.

Pour autant, il faut bien se rendre compte que c'est un problème réel du code actuel et qu'il est assez genant. Cet état + la possibilité que tu cite explique pourquoi j'ai proposé de séparer le choix final en deux : une solution moyen terme réalisable dans un temps raisonnable pour que ça ne deviennent plus une urgence et une solution long terme qui peut être ainsi plus ambitieuse et plus propre, réalisable à plus long terme si une solution temporaire est mise en place.

Bref, je suis d'accord avec toi.

Je n'ai peut-être pas tout compris, donc si je me trompe dans mon analyse corrigez-moi.

Déjà en tant qu'informaticien de base, réinventer la roue c'est une idée qui me botte pas trop. En particulier, recoder des drivers pour les différents formats, c'est un peu lourd comme boulot non ? Sachant que des gens l'ont fait avant nous.

C'est pour ça qu'utiliser Pandoc me semble pas une mauvaise chose. Et si dans un avenir proche, on veut utiliser un autre format, certainement que Pandoc aura un driver pour ce format.

Donc pour moi, utiliser Pandoc, bien que je ne connaisse pas le logiciel, revient à parser du zmarkdown vers un format spécifique, que l'on donne à manger à Pandoc et lui il fait le travaille derrière.

Donc je suppose que si on veut avoir un truc générique. Il faut grosso-modo transformer le zmarkdown vers un format intermédiaire que pandoc pourra facilement transcrire en tout ce qu'il veut non ?

Comment c'est fait actuellement la transition du zmarkdown vers pandoc ? Et pourquoi ne pas utiliser pandoc pour le html par exemple ?

En gros le truc est que pandoc prend plusieurs formats mais surtout du markdown. Pandoc a des trucs en plus et des trucs en moins. Pour l'utiliser pour le HTML il faudrait l'étendre pour supporter nos éléments de syntaxe. Et ce n'est faisable qu'en haskell.

La solution actuel et de faire des modifs minimale, dangereuses et non parfaites. Mais ces modifs appliquées à notre markdown ne peuvent pas tout faire et sont soumises aux bugs. C'est pour ça qu'il faut le changer.

Mettre a jour pandoc pour tout faire est un des cas parfait mais c'est encore le même problème, c'est actuellement qu'une solution long terme, il faut trouver un "bon" en haskell pour gérer toutes nos nouveautés de syntaxes.

Il n'y a aucune solution qui nous évite de réinventer quelque chose. Mettre a jour Pandoc est la solution consistant a mettre a jour la génération d'un ast depuis les sources, la majorité des autres solutions consiste a travailler plutôt côté génération.

Ce qui serait le mieux c'est de trouver une lib en python qui permettait de générer des pdf et ebook depuis une structure de données. En première approche on aurait juste a coder la glu entre l'ast de python-zmarkdown et le format de donnée de cette lib.

Ok.

Je commence à m'intéresser à Haskell donc ça serait une bonne source de motivation pour m'y mettre concrètement. Comme le disait nohar, quitte à créer un atelier lab, si c'est sur du long terme, on est pas pressé.

Sur le cours terme, c'est plus embêtant.

Et ce n'est faisable qu'en haskell.

J'ai envie de dire : ping GuilOooo non ?

Sinon, j'aime bien l'idée de faire des ateliers R&D pour le site

Juste histoire de prévenir, je sais coder en Haskell (par contre, je n'ai jamais ouvert le code source de Pandoc).

Je vais être très peu dispo jusqu'à septembre, mais si vous n'êtes pas pressés, je peux tenter quelque chose à ce moment-là.

Si vous voulez tenter l'aventure de coder un truc en Haskell vous-mêmes et que vous avez des questions, vous pouvez toujours m'envoyer un mail.

Merci à Alex-D d'avoir attiré mon attention sur ce topic.

Perso je connais un peu Haskell, et je pense que la solution côté pandoc revient simplement à ajouter une extension à son frontend markdown, ce qui, a priori, s'exprime plutôt naturellement dans un langage fonctionnel, et semble prévu par l'architecture de pandoc.

Je ne pense pas que ce soit un boulot lourd, ça me semble tout à fait faisable à condition que le zmarkdown soit documenté.

Par ailleurs j'ai plutôt tendance à me méfier de tout ce qui ne passe pas par LaTeX pour générer les PDF : c'est quand même LE truc fait pour ça, stable, souple et à qualité garantie. De même, mon boulot m'a appris à avoir peur des concepts du style "sérialisation d'un AST en XML", en particulier niveau perfs.

Par contre, comme solution à court terme, je ne vois pas grand chose de viable (i.e. linéaire sans dédoublement du code métier, et pas trop casse-gueule) à part une étape intermédiaire :

1

zmarkdown -> (extension python) -> markdown pandoc -> (pandoc) -> whatever

Ça revient à lisser temporairement les blocs spéciaux quand on génère un tuto (donc ça limite les possibilités pour l'output), ce qui n'est pas standalone mais peut faire le job correctement dans un premier temps. Et ça s'enchaînerait naturellement avec l'étape long terme qui revient à déporter le boulot de l'extension Python vers une extension pandoc (compilée en statique, donc probablement plus performante, et par ghc, donc certainement plus robuste).

Il faut également remarquer qu'à terme le markdown n'est pas un truc qui va bouger tous les 4 matins : on n'a pas besoin d'un sapin de Noël non plus.

Bon, je fait aussi un peu de haskell, on peut envisager de travailler en petit groupe dessus pour le migrer. Mais contrairement à ce que suppose nohar, il n'y a pas que du frontend. La majorité de nos extensions rajoutent de la sémantique. Par exemple les blocs spéciaux. Les parser c'est bien mais il faut rajouter cette notion dans l'ast et adapté les modules de rendus pour qu'il sache comment les re-sortir (avec des div+class en html/ebook, avec un environnement spécifique en latex). Donc il nous faudra très probablement mettre a jour toute la chaine !

Pour autant, Pandoc est probablement l'outil qui génère toutes les sorties qui nous arrange qui a la syntaxe la plus proche de ce qui nous arrange puisque les choix de syntaxes ont été fait en regardant avant si Pandoc avait un équivalent.

Si on part sur Pandoc, c'est pour moi une solution long terme mais il y a peut être moyen de faire des étapes intermédiaires. En effet il y a une façon d'étendre Pandoc dans n'importe quel langage, en utilisant des filtre. J'en avais pas parlé car, en gros, c'est juste une possibilité de "filtrer" l'AST généré par Pandoc. On reçoit l'AST (sous forme de flux JSon), on la filtre, on renvois une nouvelle AST et Pandoc génère les documents. Il est donc possible, en étape intermédiaire, de fournir directement l'AST a Pandoc. On peut donc imaginer une transition en plusieurs étapes :

• On fait générer une AST à Python Markdown, une par type de sortie. Pandoc est alors la version upstream et Python-Markdown se charge du front-end et des quelques spécificités lié aux différentes sorties (injecté le html ou le latex dans l'AST pour ce qui n'est pas prit en charge dans Pandoc)
• On implémente ces spécificités au fur et a mesure dans les modules de sorties : On commence à modifier Pandoc en rajoutant les types de nœuds qu'il manque et le rendu désiré dans les différents modules de sorties. A la fin de cette étape, Python-Markdown ne servirait alors plus que de frontend pour générer l'AST que Pandoc pourrait transformer dans les différentes sorties qu'on utilise.
• On finit par modifier le frontend de Pandoc pour prendre en charge nos éléments de syntaxes et Pandoc devient le seul outil nécessaire.

Ce plan d'action est celui qui me parait le plus sage si on vise une transition vers du 100% Pandoc, ça permet de bien isoler les différentes étapes et les différents modules à modifier, un par un.

Pour autant, et même si nohar semble méfiant, je pense qu'il faut discuter d'une autre option, générer le pdf depuis le html. En effet Python-Markdown nous fournit actuellement du html. Avec peu de modifs on peut lui faire générer un html "imprimable" (remplacer les liens par des notes de bas de pages ou références, remplacer les vidéos par des images, etc.). De là il est très facile de générer un ebook (qui ne sont que des fichiers html + metadata dans un zip). Reste le Pdf. Actuellement on le produit avec Latex mais je suis étonné qu'en 2014 on arrive pas à produire un pdf propre a partir de html, quitte a lui fournir les même méta-donné que pour les ebook. Cette solution aurait l'avantage d'assurer un rendu plus cohérent entre les supports.

Je reste relativement sceptique sur la génération de pdf depuis des html ou ebook mais je me dois de l'introduire dans la conversation, ça pourrait être la solution la moins couteuse en dev si on peut avoir des résultats propres.

J'ai fais quelques tests de conversion html -> pdf directement, ce n'est pas très concluant. Ça revient a créer une grosse config d'impression, c'est pas terrible en général.

Donc j'en revient a mon plan d'action vers Pandoc, faute de meilleurs idées. Des avis ?

A noter que je pense qu'à court terme, on peut aussi rajouter une pré-étape pour améliorer les choses à peu de frais : En gros déporter les scripts actuels de conversion dans python-zmarkdown et profiter de l'AST pour tous actuels + faire les transformations "vers papier" (capture des vidéos, liens affichés, etc.), générer du html et le faire convertir par pandoc vers du latex.

L'idée est donc de faire manger à pandoc du html en entrée plutôt que notre markdown qu'on va galérer à transformer de manière corrects.

Malheureusement cette solution n'est pas parfaite car l'entrée html de pandoc ne prend pas tout ce que l'on a besoin. En gros, dont je n'ai pas trouvé a priori d'équivalent générales :

• Les sémantiques que pandoc ne connait pas (Touches, bloc d'info & co, alignement, une partie des légendes…)
• Les trucs qu'il n'accepte pas en entrée html (figure principalement)

Une bonne partie peut être contourné en définissant le style à partir des autres. On peut ainsi imaginer transformer les touches en gras + casse-fixe ou des trucs dans le genre, faire les légendes manuellement (élément + br + texte en gras pour le type + : + le texte de légende), etc. Mais il y a des trucs qui resteront globalement impossibles à faire (alignement et bloc d'infos). Mais ce sont des trucs que de toute façon actuellement on ne gère pas non plus… Mais on aurait moins de probs de conversion je pense et ça permettrai déjà d'identifier clairement les éléments qu'on va devoir modifier dans Pandoc ce qui sera utile pour la suite.

Sachant que certains de ces soucis disparaîtrons quand on produira directement l'AST à Pandoc (on pourra injecter les figures puisqu'il le prend en entrée pour certains formats).

Je ne sais pas quelle serait la solution technique viable à court terme. Pour le moment, j'ai téléchargé les sources de Pandoc, je vais voir la tête qu'a l'AST et essayer d'implémenter une extension triviale à leur markdown, juste pour tester la faisabilité du truc. Je reviens vous raconter ça ici quand j'ai fini.

(Encore une fois, je fais ça sans aucune garantie, attendez-vous à ce que je disparaisse brusquement pendant 3 semaines n'importe quand d'ici septembre)

EDIT : quelqu'un a-t-il la liste des extensions ZdS maison, par rapport au Markdown de Pandoc ? Pour le moment, je vois celles-ci :

• le fait de pouvoir centrer/aligner à droite un texte (syntaxe avec les flèches) ;
• le fait de pouvoir transformer une image en figure ;
• les vidéos ;
• les touches (syntaxe avec les double-pipes) ;
• les smileys (?) ;
• les blocs spéciaux (attention, question…) ;
• les sources pour les citations ;
• les commentaires.

J'en oublie ?

EDIT 2 : pour ceux qui parlent Haskell, voici le lien vers la documentation du type “AST” de Pandoc. http://hackage.haskell.org/package/pandoc-types-1.12.3.3/docs/Text-Pandoc-Definition.html

EDIT 3 : Voici ce que je comprends de la doc et du code source. Attention, il est possible que je me plante totalement.

Pandoc possède des types “span” et “div”, qui sont grossièrement équivalents à leurs homonymes HTML. Il est donc relativement simple d'implémenter toutes nos extensions à coups de div/span + feuille de style (ou de commandes dans le préambule LaTeX). Concernant les smileys et les commentaires, il suffit de les remplacer par des images ou les supprimer (respectivement) directement depuis le parseur ; ça ne pose pas de difficultés. Enfin, concernant les sources des citations, la doc montre que le type “citation” de Pandoc possède une liste de “préfixes” et une liste de “suffixes”, qui sont des éléments inline. On peut donc gérer les sources des citations en rajoutant un élément Inline qui contient : « Source: <la source> » en suffixe.

Le gros point noir concerne les vidéos : il n'y a pas de type prévu pour, et on ne peut pas facilement les gérer à coups de div/span. On peut donc modifier l'AST de Pandoc pour rajouter un type ; c'est faisable, mais ça implique de modifier tous les writers qu'on va utiliser. (Il n'est par exemple pas évident de décider du statut d'une vidéo dans un document LaTeX). Une autre solution consiste en modifier seulement le writer HTML5, de telle façon qu'un “div” avec la classe “video” soit implicitement transformé en balise vidéo (c'est le même genre de hack qui est utilisé pour gérer <figure>, d'après ce que j'ai compris). L'avantage, c'est qu'on peut remplacer la vidéo par un simple lien textuel « consultez la vidéo à l'adresse suivante : <URL> » pour les autres writers.

Je mets en secret parce que c'est une remarque mineure.

J'ai édité mon post précédent au fur et à mesure de mes découvertes.

@Fulbert : je pense qu'on est pour le moment dans une optique de produire un PDF pour lecture sur écran ou impression personnelle. La problématique de produire du PDF pour imprimeur est assez différente. Quoi qu'il en soit, Pandoc passe visiblement par du LaTeX pour générer les PDF's, donc s'il y a moyen de produire du PDF/X 1a en LaTeX, ça ne devrait pas nous poser de problèmes.