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

Merci pour ce message récapitulatif !

En ce qui concerne la coloration, je suis de ton avis : dans un premier temps, optons pour la solution la plus simple, d'autant plus qu'elle semble ne pas demander de dev particulier vu qu'elle est intégrée à pandoc. On optimisera au besoin quand tout fonctionnera.

Par rapport à la gestion des documents, je pense qu'il faut opter pour la solution la plus modulaire. Je n'ai pas tous les outils en main pour juger de laquelle ce sera, mais il est judicieux, à mon avis, que notre interprétation des documents n'influe pas trop pandoc. Je crains sinon que le fork soit extrêmement relié au projet. Peut-être est-ce l'objectif après tout, mais n'est-il pas dommage de faire un truc ne fonctionnant que pour notre syntaxe ? Ne serait-ce qu'au cas où on souhaiterait la modifier plus tard.

Pour ce qui est de ma participation, je n'aurai pas le temps avant un bon moment (concours obligent). Par contre, je veux bien faire le débutant cobaye : en partant du principe que je possède des notions de base en Haskell, tu m'expliquerais comment fonctionne le programme à personnaliser, de sorte que je devienne autonome. Je prendrai alors le temps d'expliquer tout ça aux autres dans un papier afin qu'apporter sa contribution soit plus aisé. Je vais déjà, pendant les vacances, étudier cette vidéo.

Concernant la gestion de d'oc, dans le fork, actuellement le binaire Pandoc reste compatible avec celui upstream. A un ou deux détails prêts, notre fork ne fait que rajouter des options.

Cependant on a besoin d'une appli pour composer les documents. On a deux solutions : une nouvelle appli en haskell qui peut ainsi reprendre le gros du code ou une appli en python qui pourra être utilisé avec un Pandoc classique mais nécessitera certains nouveaux dev.

Dans tous les cas on a besoin d'une nouvelle approche, reste a savoir en quel langage on le fait.

Grâce a la remarque de Vayel j'ai un peu réfléchi et trouver une solution compromis : faire tout ça en python, sans refaire le dev de génération de latex ou ebook en utilisant le fait que Pandoc peut sérialiser / de sérialiser son AST en JSON. Du coup on ferait toute la manipulation de l'ast en python et la redonnerai en entrée de Pandoc pour la génération des sorties.

Des news: j'ai un peu avancé durant les vacances. Le parsage de toutes nos syntaxes est actuellement opérationnel et le latex est généré. Il y a des trucs à revoir mais ça fait une base. J'ai commencé un module Python pour pouvoir demander le parsage d'un document, en manipulant de façon transparente et propre l'AST. Ça permettra de ne pas rendre notre fork obligatoire, une version de base de pandoc pourra faire l'affaire.

J'ai un peu mit en pause ça ces dernières semaines, manque de temps. Actuellement le point bloquant que j'ai est purement latex : les environnement verbatim (les codes donc) ne peuvent pas être insérés dans certains autres environnements (entre autre les mini-pages) ce qui empêche de transformer un document qui contiendrait du code dans une balise info ou une citation. J’ai peut être trouvé une voie détourné mais c'est pas si simple que ça.

Et en utilisant une variante de verbatim à la place ? Genre fancyvrb, ou une autre amélioration du package.

J'utilise déjà fancyvrb en fait. J'ai plus ni l'erreur ni les solutions possible sous la main mais en gros une solution est de déclarer le contenu d'une part et de l'insérer dans l'élément avec une autre.

Je me demandais à quel niveau on plaçait les extensions pour le rendu. Par exemple, si on doit rajouter des ancres pour les titres, cela se fera-t-il en personnalisant le writer HTML ou en ajoutant un script Python derrière ?

En faisant rien c'est déjà gérable par pandoc en l'activant

En général il faut modifier le parseur pour prendre en compte la syntaxe et les writers pour adapter les sorties.

Il faut que j'avance la dessus…

Bon des nouvelles. Apres une pose, je me suis remis dessus. J'ai identifié le bug actuel exposé ici. Il s'agit d'un conflit entre le code qui génère les boites de rendus et les codes.

J'ai rien trouvé sur le net pour régler ce soucis facilement mais il y a une solution simple qui reglerait une autre question : passer au package listing pour la coloration du code en latex. Alors on perderai le coté "exactement le même rendu sur toutes les plateformes" mais au moins ça débloquerait la ZEP et ça ne serait pas choquant : listing est la référence des outils de colorations de code sous Latex.

Je n’y vois pas d’inconvénient. D’autant plus que le rendu de listing pourra être éventuellement ajusté avec \lstdefinestyle afin d’avoir un style plus homogène si nécessaire.

Bon j'ai changé comment je faisait le rendu des blocs et c'est passé. Je vous propose un pseudo rendu d'article : Celui sur le C++14 chez nous et la version PDF que j'obtiens

Je vais rajouter d'autres exemples mais si ça vous dit de comparer, n'hésitez pas. Actuellement les problèmes principaux que je note :

• dans les blocs de code non colorés, des caractères semblent se chevaucher
• les secrets sont dans des blocs et non dans des blocs de fin de pages¹
• tableaux avec inline qui dépassent : ça j'ai aucune idée comment le résoudre.

Si vous avez d'autres remarques, n'hésitez pas

Le smiley en footnote est trop grand (première page). Sinon il est possible de rendre les notes de bas de page cliquables (et je ne sais pas si on peut revenir en arrière par contre). Tu as fait le choix de ne pas les rendre cliquable ?

Ha oui le smiley j'avais vu mais oublié de le noter. Pour les notes de bas de pages, je sais pas, mais j'ai visé un pdf imprimable, pas pour la consultation en ligne

Pour moi c'est encore un peu stylisable pour en faire un truc un peu moins papier scientifique et un peu plus tuto de ZdS. Par exemple avec une page de garde, un changement de police et une stylisation des titres/zones de code en accord avec le site. Sinon ça semble marcher plutôt bien !

En plus des remarques de Luthaf que je plussoie, un sommaire à un seul niveau sur un article de cette taille serait vachement sympa. Et encore mieux si on avait des liens clicables (oui je lis en général sur ordi/tablette)

Le sommaire, en effet c'est facile a ajouter. Les liens, le soucis, c'est que de bases ils sont insécable et du coup dans l'article précédent, des la première ligne, tu te retrouve avec un texte qui sort du paragraphe. Et ça surcharge un peu le texte.

La page de garde, pour un article, ça le parrait overkill mais pourquoi pas.

Le reste, j'ai autant de goût qu'une huitre donc si quelqu'un veut le guider sur les styles, j'appliquerai ce qu'on le dira

Pour la page de garde je ne pense pas que ce soit utile pour un article, pour un tuto pourquoi pas. Par contre un encadré précisant que c’est un PDF généré automatiquement par Zeste de Savoir ça peut être bien oui.

Le style maintenant je suis d’accord avec Luthaf, on peut au moins essayer de mettre les même polices que le site.

Sinon le rendu est vraiment pas mal pour un truc automatique !

Si c'est pas la même police que le site c'est que je l'ai mal installé, c'est facile à régler.

Ce qui me gène actuellement le plus c'est de ne pas pouvoir passer les secrets en note de fin. Le reste est globalement du détail je pense.

Pour le rendu, si quelqu'un me fait une maquette du design du pdf à obtenir, je tenterai d'adapter. En attendant je me concentre sur sortir un pdf propre plus qu'un pdf joli.

edit: bon les notes de bas de pages dans des notes de bas de page (dut aux liens auto) semble poser problème, il en manque sur la première page.

Plutot que des notes de bas de pages pour les liens, peut être faire une section "référence" ?

Plutot que des notes de bas de pages pour les liens, peut être faire une section "référence" ?

Définitivement, une section bibliographie serait bien adaptée je pense.

Je vous propose une nouvelle passe de "style" et voici le nouveau PDF.

Au menu : mêmes police que sur le site, de la couleur dans les titres, une table des matières, les problèmes de caractères qui se chevauchant dans les codes non colorés et au passage je suis en train de régler le soucis des smileys.

Si cette version vous semble plus dans le style de ZDS et acceptable, j'utiliserai ça comme base : je corrigerais les imperfections perfectibles qui sont possibles "facilement" et je ferai des essais sur d'autres articles.

Le seul truc qui me chiffonne est le style des zones de code. J'ai du mal avec l'encadré et le fond gris. Mais à part ça, c'est mieux !