La syntaxe markdown zds n'est pas mise en forme sur les pdf exportés

[roipoussiere]

Pour reproduire :

• créer un nouveau tutoriel ;
• insérer le texte suivant :

||une touche||

[[information]]
| Une information

• exporter le tutoriel en PDF.
• constatez que la syntaxe markdown n'est pas mise en forme sur le PDF :

cc ticket sur ZestWriter

[cgabard]

Oui, cf ZEP-5 et les pages de discussions à ce sujet. Envoi moi un MP si tu veux un résumé rapide

[roipoussiere]

Hello, du nouveau ici ?

En fait je relance parce que j'avais l'idée d'imprimer un petit tuto vite fait pour le Capitole du Libre, histoire de pouvoir montrer un petit truc concret en plus.

Il y a des chances pour que ce soit résolu avant fin octobre ?

[Situphen]

En étant réaliste, non. :)

[GerardPaligot]

@roipoussiere Aucun PDF déjà généré pourrait faire l'affaire ?

[roipoussiere]

Si bien sur, mais je n'en ai aucun. :-)

[roipoussiere]

En passant j'ai testé la conversion zMd -> html5 qui fonctionne correctement, mais pour le generate_pdf de zds_site semble faire une conversion directe Pandoc(zMd -> pdf) et pas PyzMd(zMd -> html5), puis pandoc(html5 -> pdf). Le problème ne vient pas de là ?

[pierre-24]

Ben on le fait parce que c'est possible avec Pandoc, sans avoir vraiment réfléchis à des alternatives. Le rendu est mieux ?

[cgabard]

Le gros problème est que le HTML généré n'est pas adapté à l'impression

Le mar. 18 oct. 2016 11:35, Pierre Beaujean notifications@github.com a
écrit :

Ben on le fait parce que c'est possible avec Pandoc, sans avoir vraiment
réfléchis à des alternatives. Le rendu est mieux ?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3683 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF0jfNx4uTjWSynyZ9snKdz6C0OvN2zDks5q1JLFgaJpZM4I-oBI
.

[roipoussiere]

Ben on le fait parce que c'est possible avec Pandoc

Mais comment Pandoc peut connaître la syntaxe zMarkdown ?

[pierre-24]

... Tu as compris tout le problème ;)

Et c'est ça qui est merdique, c'est qu'il faut (ré)écrire toute la partie de Pandoc qui gère le markdown pour lui faire comprendre le zMD, et du coup ça avance pas par manque de motivation.

[roipoussiere]

il faut (ré)écrire toute la partie de Pandoc qui gère le markdown pour lui faire comprendre le zMD

Pourquoi ne pas simplement convertir le zMd en html5 avec PythonZMarkdown, puis convertir le html5 en pdf avec Pandoc ?

Ah, je viens de voir que Pandoc ne peut importer que du html, pas du html5, le problème vient de là ?

[cgabard]

Non le gros du problème est que le HTML n'est pas adapté. Toutes les
balises spécial, les videos et pas mal d'autres trucs seront pas où mal
converti. Faut faire une conversion guidé

Le mar. 18 oct. 2016 12:04, Nathanaël Jourdane notifications@github.com a
écrit :

il faut (ré)écrire toute la partie de Pandoc qui gère le markdown pour lui
faire comprendre le zMD

Pourquoi ne pas simplement convertir le zMd en html5 avec PythonZMarkdown,
puis convertir le html5 en pdf avec Pandoc ?

Ah, je viens de voir que Pandoc ne peut importer que du html, pas du
html5, le problème vient de là ?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3683 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF0jfGhdpkU2NQ3bV-2cjw5ZCe1WOFYYks5q1JmWgaJpZM4I-oBI
.

[vhf]

Je suis d'accord que faire md -> html -> pdf ne sera jamais bien. Mais md -> pdf, y'a des solutions. J'ai pas étudié la question mais certains semblent le faire avec plus ou moins de succès.

exemple

[roipoussiere]

Et en implémentant l'export LaTeX dans PythonzMarkdown ? Ça donnerait PyzMd(zMd -> LaTeX), puis pandoc(LaTex -> pdf)

Les solutions md -> pdf je ne suis pas sur que la mise en page soit d'aussi bonne qualité que celle que te sort LaTeX, avec gestion des TOC, footnotes, numéros de pages, chapitres, etc.

[cgabard]

Heu non. Ou en tout cas c'est loin d'être simple. J'ai déjà essayé de faire
un fork de pandoc pour générer du latex mais ça pose plein de problèmes.

À court terme le mieux est probablement de gérer un HTML dédié à
l'impression et de faire un pdf avec un css dédié. Mais le zmarkdown est
pas vraiment prêt

Le mar. 18 oct. 2016 14:11, Nathanaël Jourdane notifications@github.com a
écrit :

Et en implémentant l'export tex dans PythonzMarkdown ? Ça donnerait
PyzMd(zMd -> LaTex), puis pandoc(LaTex -> pdf)

Les solutions md -> pdf je ne suis pas sur que la mise en page soit
d'aussi bonne qualité quelle que te sort LaTex, avec gestion des TOC,
footnotes, numéros de pages, chapitres, etc.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3683 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF0jfBUGWSYd59hOh3J89a3OH3ICQNd3ks5q1LdrgaJpZM4I-oBI
.

[roipoussiere]

@roipoussiere Aucun PDF déjà généré pourrait faire l'affaire ?

C'est à dire qu'à un moment ça marchait ? Si oui, je veux bien que quelqu'un m'envoie un PDF déjà généré. :-)

[GerardPaligot]

C'est à dire qu'à un moment ça marchait ? Si oui, je veux bien que quelqu'un m'envoie un PDF déjà généré. :-)

Non mais peut-être qu'il y a des PDFs qui n'utilisent pas trop notre syntaxe et qui aurait donc un rendu pas trop moche.

[pierre-24]

Typiquement, et je suis désolé pour cette pub honteuse, celui là

[SpaceFox]

Puisqu'on est dans la pub éhontée, ce tuto a eu son petit succès et a un
PDF tout à fait valable :
https://zestedesavoir.com/tutoriels/pdf/305/pourquoi-vous-devriez-avoir-une-peluche-sur-votre-bureau.pdf
(les autres que j'ai écrits utilisent pas mal les balises ZdS, sauf mon
dernier article
https://zestedesavoir.com/articles/1522/reflexions-sur-lart-libre-et-son-avenir/
mais pour une raison inconnue, il n'a pas de version PDF).

2016-10-18 16:06 GMT+02:00 Pierre Beaujean notifications@github.com:

Typiquement, et je suis désolé pour cette pub honteuse, celui là
https://zestedesavoir.com/tutoriels/pdf/245/la-recherche-dinformations-sur-internet.pdf

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3683 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFhKnIrqW4cb2UyzbtPw2sMeqJKLluzvks5q1NJZgaJpZM4I-oBI
.

[GerardPaligot]

Avec le tutoriel sur la peluche, il y aurait même une histoire à raconter quand on présente le PDF (le buzz toussa toussa). (:

[pierre-24]

plusun :p

[vhf]

Pourquoi pas Md->Latex->PDFLatex ?

J'y pensais ce midi, je me disais que si le parseur est pas trop mal fichu et qu'on a accès à l'AST, produire du latex doit pas être insurmontable (comparé à forker Pandoc pour lui faire piger le zmarkdown).

Du coup j'ai un peu cherché, et ça va pas 100% convenir mais ça peut très probablement servir de base, voici quelqu'un qui a déjà tenté de générer du latex depuis python-markdown: https://github.com/rgrp/markdown2latex

[AmarOk1412]

Comme dit sur IRC, cette issue m'intéresse, et que je suis pour le zmd->LaTeX->pdflatex. Je testerais quelques outils pour voir ce que ça donne ce week end

[pierre-24]

J'y pensais aussi. Je me demande comment travaille notre propre parser et à quel point il y a moyen de lui faire cracher du LaTeX (mais je lache ça sans savoir comment fonction pytjon-zmarkdown). Sinon, effectivement, chipoter un outil existant.

[roipoussiere]

En gros faut ajouter un nouveau type d'export zMd ici.

@vhf et @AmarOk1412 je ne sais pas si j'étais clair mais c'est exactement à quoi je pensais. ;-)

Je veux bien vous filer un coup de main si besoin, notamment s'il faut écrire des directives LaTeX.

[vhf]

Exact @roipoussiere . Ce sera pas de refus pour l'aide LaTeX, on hésitera pas à te contacter.

[pierre-24]

@roipoussiere : comme je le vois, il faudrait faire un peu de recherche sur un paquet qui affiche du code (ou alors on applique la coloration syntaxique et on le change en LaTeX, mais ça me semble plus cochon), et un qui fait des cadres colorés pour info/attention/...

Pour le moment, je vois pas trop d'autres problèmes avec LaTeX (faut juste faire attention à échapper les caractères "%" et "")

[roipoussiere]

il faudrait faire un peu de recherche sur un paquet qui affiche du code

Pour ça il n'y a pas de soucis, j'ai déjà fait ça dans un rapport de stage.

C'est pour les touches (||key||) que je ne voyais pas trop comment faire, mais au pire on se fait notre propre paquet qui gère ça.

Je pense que si je me penche sur le LaTex j'en profiterais pour faire le ménage dans les dépendances car là le script d'install est super, super long...

[pierre-24]

Avec un équivalent de \framebox, y'a probablement moyen. Y'a juste que les box en latex ne passent pas à la ligne (minipage, toussa), c'est le seul problème que je vois ;)

[cgabard]

Vous pouvez essayer mais je vous conseille de lire le long thread sur la
zep en question. Plusieurs problèmes :

• zmarkdown n'a PAS d'AST, il construit un arbre HTML au fur et à mesure ce
  qui rend la production de latex à partir de ça a peut prêt équivalente à
  une conversion HTML vers latex.
• le latex pose problème quand je fesait mes essais en particulier le rendu
  de tableaux un peu grand ou avec du contenu "pas que texte" à l'intérieur.
  Il y en a d'autres.

Après tous mes essais j'en étais à la conclusion qu'il fallait mieux finir
de nettoyer le zmarkdown, le faire passer à une vrai AST e, à partir de la,
soit choisir de retenter le latex soit faire un HTML à destination de
l'impression qui, avec un peu de css dédié pourrait produire un pdf viable.

Si vous êtes vraiment intéressé on peut en discuter mais le problème est
loin d'être trivial.

Je cherche du temps en ce moment pour continuer le ménage de zdm

Par contre si voulez des pdf propre, j'ai quelques articles généré pendant
mes tests qui rendent bien mais bon

Le mer. 19 oct. 2016 16:59, Nathanaël Jourdane notifications@github.com a
écrit :

il faudrait faire un peu de recherche sur un paquet qui affiche du code

Pour ça il n'y a pas de soucis, j'ai déjà fait ça dans un rapport de stage.

C'est pour les touches (||key||) que je ne voyais pas trop comment faire,
mais au pire on se fait notre propre paquet qui gère ça.

Je pense que si je me penche sur le LaTex j'en profiterais pour faire le
ménage dans les dépendances car là le script d'install est super, super
long...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3683 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF0jfLTU3y8EqN2NCCJ8BLqNdbQOTRQlks5q1jBmgaJpZM4I-oBI
.

[roipoussiere]

zmarkdown n'a PAS d'AST

Je ne vois pas trop le pb, pour moi il suffit de changer la syntaxe de sortie, ie à la place de <kbd>touche</kbd>, on met \zds_kbd{touche}, et on décrit le comportement de la syntaxe dans un fichier LaTeX à part.

faire un HTML à destination de l'impression qui, avec un peu de css dédié pourrait produire un pdf viable.

J'ai quelques doutes là dessus. LaTeX gère pleins de trucs tout seul au niveau de la mise en page, genre placer les images au bon endroit, ajouter les footnotes, etc.

Par contre si voulez des pdf propre, j'ai quelques articles généré pendant mes tests qui rendent bien mais bon

En fait ce n'est pas nécessaire, Je peux exporter n'importe que contenu du site et le convertir en pdf avec ZestWriter. ;-)

[pierre-24]

@cgabard n'as pas forcément tord pour l'AST. Ce n'est pas (tout à fait) un problème, mais ça simplifie largement l'affaire : une fois qu'on a l'AST on peut virtuellement tout faire.

Bien vu pour les tableaux à textes complexes, j'y avais pas pensé. Il y a toujours moyen de s'en sortir (en mettant les colonnes à p ou en utilisant tabulary, mais c'est vrai que ça mérite un ou deux tests.

[vhf]

Disons que python-markdown a un AST, mais que c'est un ElementTree et que c'est pas adapté. Ni dans le cas général, ni dans le cas d'HTML. Limite pour du XML, mais bon.

Peut-être que se départir de python-markdown résoudrait des trucs. On y a au moins une suite de tests de grande qualité, et ça c'est vraiment important.

Parmi nos options, il y a

• Continuer avec python-zmarkdown
• Carrément arrêter avec python et passer à un truc super propre comme remark
• Implémenter un parser markdown généraliste en python puisqu'il n'y en a pas qui semble super, qui sera utilisé par le monde entier, idéalement en se basant sur mdast, qui est super à mon avis
• Repartir sur un autre parser markdown en python qui a un AST plus propre, du genre CommonMark-py ou mpiece

[roipoussiere]

En fait je crois que je ne comprends pas très bien ce qu'est AST et en quoi cela pose problème que PyZMd ne soit pas AST.

[cgabard]

Avec un clavier, quelques précisions :

• Rien que les bonnes classes latex posent des problèmes. Mon dernier essai peut être trouvé ici : https://zestedesavoir.com/forums/sujet/676/zep-05-refonte-du-traitement-markdown-pour-lexport/?page=14#p99600 (il y a dans le tas des pdf propres si vous en avez besoin) et tout un tas de problèmes (qui ne correspondent qu'à ceux trouvé dans des articles). J'ai les sources latex normalement si ça vous intéresse comme base
• Générer le latex depuis (notre) markdown est actuellement non-trivial :

Je ne vois pas trop le pb, pour moi il suffit de changer la syntaxe de sortie, ie à la place de touche, on met \zds_kbd{touche}, et on décrit le comportement de la syntaxe dans un fichier à part.

Pour un kbd, oui c'est simple. Quand tu va voir que tu va devoir convertir un tableau html (contenant des row/cols span), un div avec des iframes dedans pour les vidéos, les notes de bas de pages dont tu ne verra que les liens, etc. là tu comprendra pourquoi c'est un problème. C'est pas pour rien que vhf parle d'AST plus haut... Sinon a priori il te "suffit" de trouver un convertisseur html > latex, ça doit pas etre compliqué selon ta logique

Sinon :

J'ai quelques doutes là dessus. LaTeX gère pleins de trucs tout seul au niveau de la mise en page, genre placer les images au bon endroit, ajouter les footnotes, etc.

Après plusieurs dizaines d'heures passé dessus, cela me semblait le mieux. Mon idée était d'utiliser des choses comme http://weasyprint.org/ qui sont dédié à ces problèmes. Pour moi c'était le meilleur compromis à tester.

Note d'ailleurs que les placements automatique ça va poser des problèmes vu que des auteurs écrivent "Comme on voit sur l'image ci-dessous..."

En fait ce n'est pas nécessaire, Je peux exporter n'importe que contenu du site et le convertir en pdf avec ZestWriter. ;-)

Bin je comprend plus... ZestWriter ça fait des pdf depuis le html non ? Si ça te suffit pourquoi tu veux du latex ? Ceux que je te propose dans l'archive plus haut sont fait spécialement avec latex. Vu que tu en demandais, je te les propose.

Bien vu pour les tableaux à textes complexes, j'y avais pas pensé. Il y a toujours moyen de s'en sortir (en mettant les colonnes à p ou en utilisant tabulary, mais c'est vrai que ça mérite un ou deux tests.

Oui et non. Je me suis beaucoup battu avec les tableaux latex. Mon problème était qu'il n'y avait pas de solution "tout en un". Il y a des extensions pour les tableaux sur plusieurs pages, d'autres qui gèrent bien les largeurs des colonnes avec du contenu complexes, etc. mais j'ai pas trouvé de solutions qui résout tout. Rien que les tableau avec le code "inline" (qui sont censé être insécable) pose des problèmes et casse tout.

Le gros soucis est qu'il faut faire du code latex générique et c'est vite la merde.

---

Pour répondre à @vhf , c'etait la conclusion où on était. J'ai commencé par compléter nos tests et stabiliser notre markdown mais j'ai pas encore tout a fait fini. On était plus partit sur l'option "faire évoluer python-zmarkdown" pour lui introduire une AST mais ça demande du boulot (et là j'était encore au travail préparatoire, blinder de tests et mettre le minimum au propre).

Note au passage sur l'option "Implémenter un parser markdown généraliste..." je tiens a vous avertir que c'est loin, très loin d'être simple. Le markdown est un langage hautement pourri et chiant a parsé (il est contextuel et ambiguë par exemple).

Ce qui me fait peur a changer de parseur c'est qu'on risque d'avoir des incompatibilités au basculement (entre autre par ce que c'est un langage ambiguë)

---

Perso si je dégage du temps je vais continuer à avancer comme prévu mais si vous voulez tenter de faire vos conversions, faites. Je peux vous fournir les fichiers latex que j'avais généré déjà. Réussir a bien tout rendre en latex est déjà un travail en soit (avant meme de le générer). Mais quand j'avais demandé de l'aide en latex j'avais pas eu beaucoup de réponses...

[vhf]

Merci pour cette vue d'ensemble @cgabard .

Note au passage sur l'option "Implémenter un parser markdown généraliste..." je tiens a vous avertir que c'est loin, très loin d'être simple. Le markdown est un langage hautement pourri et chiant a parsé (il est contextuel et ambiguë par exemple).

Toutes les ambiguïté du Markdown originel sont résolues par CommonMark, donc on pourrait partir là-dessus. Et je sais pas à quel point un port python de remark-parse serait compliqué.

Je sais pas si c'était dans tes plans initiaux @cgabard, mais si tu décides de faire une énorme refacto de python-zmarkdown pour qu'il ait pour intermédiaire un vrai AST, je pense que ça vaudrait la peine d'en faire un projet séparé, qu'on étendrait avec nos propres plugins propres à zmarkdown ?

[cgabard]

Toutes les ambiguïté du Markdown originel sont résolues par CommonMark, donc on pourrait partir là-dessus. Et je sais pas à quel point un port python de remark-parse serait compliqué.

Oui et Non. Certes ces markdown sont censés être compatible entre eux (je ne sais pas a quel point commonmark et les autres implémentations sont stable vu que des v1 ne sont pas encore sortie) mais le soucis est que notre markdown n'est pas compatible, lui. Du coup on se paie une migration "dangereuse" (par exemple un message qui était parsé d'une façon et après un edit annexe il ne l'est plus)

---

Je sais pas si c'était dans tes plans initiaux @cgabard, mais si tu décides de faire une énorme refacto de python-zmarkdown pour qu'il ait pour intermédiaire un vrai AST, je pense que ça vaudrait la peine d'en faire un projet séparé, qu'on étendrait avec nos propres plugins propres à zmarkdown ?

En fait j'ai déjà arreté de me rebasé sur le projet upstream et fait quelques modifs qui le rendrait difficile. Oui l'idée était d'y aller franco en réalité. Une fois les tests assez fort (c'est globalement le cas là), il faut convertir certaines vieilleries de Python-Markdown (il y a des étapes de préprocess à la con qui empeche de faire certaines choses proprement, c'est ce que j'étais en train de faire).

L'étape suivante aurait été d'ajouté quelques petites extensions (les mentions) et après je voulais continuer en virant tout le code que nous on utilise pas et intégré nos extensions a peut pret de la même façon que les blocs de bases.

Donc le projet est déjà plus ou moins séparé de l'upstream et le but n'était pas de maintenir la compatibilité.

[roipoussiere]

Repartir sur un autre parser markdown en python qui a un AST plus propre, du genre CommonMark-py ou mpiece

J'ai regardé CommonMark-py, ça semble faire l'affaire en effet.

Bin je comprend plus... ZestWriter ça fait des pdf depuis le html non ? Si ça te suffit pourquoi tu veux du latex ? Ceux que je te propose dans l'archive plus haut sont fait spécialement avec latex. Vu que tu en demandais, je te les propose.

Passer par ZestWriter produit des pdf foireux mais je pensais c'était ça que tu me proposais. :-) Je ne savais pas que ce que les pdfs tu me proposais étaient full-markdown, donc je suis intéressé. Quelle archive plus haut ?

Après plusieurs dizaines d'heures passé dessus, cela me semblait le mieux. Mon idée était d'utiliser des choses comme http://weasyprint.org/ qui sont dédié à ces problèmes. Pour moi c'était le meilleur compromis à tester.

J'ai regardé l'outil et ça me semble pas trop mal. Je vois également d'autres avantages :

• si on a un fichier CSS, on pourra avoir un rendu identique avec ce qui est sur le site ;
• on aura pas une super longue install a faire pour avoir LaTeX sur sa machine, ni les quelques Go nécessaires ;
• actuellement, ZestWriter ne convertit pas tout seul les fichiers HTML en pdf, mais passe par un VPS perso, justement parce que la conversion nécessite LaTeX, qui est lourd et ne peut pas être inclu dans ZestWriter. En faisant une converstion zMd->HTML->PDF on aurait un truc tout léger, donc il serait possible d'intégrer l'export pdf directement dans ZestWriter, ce qui serait vraiment top. (voir même avoir une preview du PDF en temps réel). cc @firm1 .

[SpaceFox]

si on a un fichier CSS, on pourra avoir un rendu identique avec ce qui
est sur le site ;

Pour moi tout l'intérêt d'avoir un PDF, c'est de ne pas avoir un rendu
identique au site, mais quelque chose d'adapté soit à l'impression, soit à
la lecture sur écran.

Le 19 octobre 2016 à 18:07, Nathanaël Jourdane notifications@github.com a
écrit :

Repartir sur un autre parser markdown en python qui a un AST plus propre,
du genre CommonMark-py ou mpiece

J'ai regardé CommonMark-py, ça semble faire l'affaire en effet.

Bin je comprend plus... ZestWriter ça fait des pdf depuis le html non ? Si
ça te suffit pourquoi tu veux du latex ? Ceux que je te propose dans
l'archive plus haut sont fait spécialement avec latex. Vu que tu en
demandais, je te les propose.

Passer par ZestWriter produit des pdf foireux mais je pensais c'était ça
que tu me proposais. :-) Je ne savais pas que ce que les pdfs tu me
proposais étaient full-markdown, donc je suis intéressé. Quelle archive
plus haut ?

Après plusieurs dizaines d'heures passé dessus, cela me semblait le mieux.
Mon idée était d'utiliser des choses comme http://weasyprint.org/ qui
sont dédié à ces problèmes. Pour moi c'était le meilleur compromis à tester.

J'ai regardé l'outil et ça me semble pas trop mal. Je vois également
d'autres avantages :

• si on a un fichier CSS, on pourra avoir un rendu identique avec ce
  qui est sur le site ;
• on aura pas une super longue install a faire pour avoir LaTeX sur sa
  machine, ni les quelques Go nécessaires ;
• actuellement, ZestWriter ne convertit pas tout seul les fichiers
  HTML en pdf, mais passe par un VPS perso, justement parce que la conversion
  nécessite LaTeX, qui est lourd et ne peut pas être inclu dans ZestWriter.
  En faisant une converstion zMd->HTML->PDF on aurait un truc tout léger,
  donc il serait possible d'intégrer l'export pdf directement dans
  ZestWriter, ce qui serait vraiment top. Et même avoir une preview du PDF en
  temps réel. cc @firm1 https://github.com/firm1 .

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3683 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFhKnB8b9CGS9brOa8fgQcm3Qs3NQ5kDks5q1kBXgaJpZM4I-oBI
.

[cgabard]

J'ai regardé CommonMark-py, ça semble faire l'affaire en effet.

Comme je l'ai dit, outre re-dev nos extensions il faut vérifier les compatibilités pourries du markdown

Passer par ZestWriter produit des pdf foireux mais je pensais c'était ça que tu me proposais. :-) Je ne savais pas que ce que les pdfs tu me proposais étaient full-markdown, donc je suis intéressé. Quelle archive plus haut ?

Dans e message : https://zestedesavoir.com/forums/sujet/676/zep-05-refonte-du-traitement-markdown-pour-lexport/?page=14#p99600 il y a le liens vers une archive contenant plein de pdf généré.

J'ai regardé l'outil et ça me semble pas trop mal. Je vois également d'autres avantages : ...

C'était l'idée. Globalement ce sera probablement pas aussi parfait que du latex mais si c'est suffisamment propre ça sera plus facile à maintenir et moins lourd pour la plateforme.

Cela demande cependant de tester. Pour ça il faut avant pouvoir générer un html "pour l'impression", entre autre :

• Les vidéos doivent être inséré avec des images + liens,
• Les abbreviations doivent être regroupés quelque part (en début fin de texte).
• Les liens doivent être regroupés ou transformé en note de bas de page
• Toutes les notes de bas de pages doivent être des vrais, pas des trucs en fin de document.
  etc.

Et pour faire ça l'idéal serait d'avoir une AST. Ceci dit avec une AST il sera aussi facile de généré un latex. Cela pourrait être une première solution (le html) avant de retenter de repasser par latex.

[roipoussiere]

Pour moi tout l'intérêt d'avoir un PDF, c'est de ne pas avoir un rendu identique au site, mais quelque chose d'adapté soit à l'impression, soit à la lecture sur écran.

Oui, ce que je voulais dire, c'est qu'on pourra reprendre certains éléments comme kbd ou block et seulement adapter un peu (au niveau des couleurs principalement) pour que ça passe bien à l'impression, mais pas avoir 2 trucs complètement différents.

[anayrat]

C'est peut être possible en utilisant les filtres pandoc?

https://github.com/chdemko/pandoc-latex-tip

[AmarOk1412]

@artragis je serais d'avis de fermer cette issue.

[artragis]

#4391 implémente déjà ça. Du coup je ferme pour laisser à l'issue concernée le droit d'exister