Bon a défaut d'avoir le temps d'avancer, je suis en train de préparer une nouvelle version du markdown pour que les améliorations des tableaux et balises maths arrivent sur zds.
Cool. Et quid de l’extension typographie ?
Il faudrait que je m'en occupe, tout comme le ping et finir la mise a jour des légendes (mais pour ce dernier point j'ai un gros problème de compatibilité que je ne sais pas comment résoudre). Malheureusement j'ai pas beaucoup de temps en ce moment.
Bon bonne nouvelle, après ma grosse période de boulot, j'ai dégagé du temps. J'ai réussi à me débloquer et ré-écrit pas mal de choses. Les légendes sont, entre autre, maintenant gérés proprement et j'ai réglé une petite dizaines de bugs connus.
Il me reste quelques extensions à remettre au propre et à tester proprement et je vais pouvoir passer au traitement des PR.
La bonne nouvelle du jour est que j'ai fini le ménage des extensions et les tests qui vont avec.
La mauvaise est que on FAI de m**** (acronyme de 3 lettres), à décidé de me priver d'Internet pour le week-end donc il faudra attendre un peu pour que je puisse pousser ces corrections de bugs et m'occuper des PR.
Bon en fait ma connexion internet est revenue, j'ai put traiter la PR des pings et elle sera mise à disposition de zds d'ici peu !
Bon dernières infos :
Je vais attendre un peu pour lancer la discussion sur les objectifs post-v1, je me méfie de mon temps de disponible qui est fluctuant.
Bon la PR de Dominus sur la typographie française est mergé et sera intégré avec le reste. Probablement plus impactant, Andr0 a fait son travail et les pings sont intégrés dans la même PR !
J'explorais vaguement le dépôt dans le but d'y consacrer par la suite un peu de temps libre. Je vois qu'il s'agit d'un fork de Python-Markdown et pas juste une collection d'extensions. Y a-t-il des changements apportés sur le cœur du moteur ou les différences avec Python-Markdown ne sont-elles que cosmétiques ?
Aussi, il me semble que Python-Markdown et ses extensions sont écrits pour produire une sortie HTML uniquement, est-ce cette sortie qui sera utilisée pour générer les documents ebook et PDF ? Ou une génération au format LaTeX est-elle envisagée ?
Je crois avoir croisé des messages (que je ne retrouve plus) de nohar parlant de Python-ZMarkdown interfacé avec Sphinx, comment cela est-il envisagé ?
Merci.
Edit : Je remarque aussi que je n'ai pas encore lu cette discussion, je vais peut-être commencer par là.
Si tu lis la zep5 tu n'as pas fini et l'historique est treeees long. Je vais te faire un résumé.
Alors oui notre zmarkdown est un fork de python-markdown. Pendant très longtemps je l'ai maintenu comme une collection d'extension et je rebasai sur l'upstream.
Ensuite j'ai dut faire quelques petites modifications en plein milieu. Il a été décidé, je vais y revenir, de se passer du rebase. Donc je me suis permis quelques autres petites modifs. Récemment j'ai fait quelques plus gros changements : j'ai transformé quasiment tous les preprocessing en parseur de blocs. Il y a de très bonnes raisons à ça mais du coup ça a déplacé et modifié plusieurs centaines de lignes. Enfin récemment aussi j'ai commencé a virer tout ce qui était inutile pour nous. Pour le moment C sont surtout les extensions qu'on utilise pas. Enfin j'ai re-ecrit quelques extensions qui posaient problème.
Actuellement ça serait donc la misère à rebaser mais le coeur est largement similaire voir identique sur de larges portions.
Pourquoi j'ai fait ça ?
Le but de la zep 5 est de produire des ebook et pdf. Pour le premier, c'est basé sur du HTML, on pourrait s'en sortir. Pour les pdf j'avais longtemps tenter de faire un fork de pandoc. J'ai réussi à avoir des pdf potable (en passant par latex) mais il restait pas mal de boulot. Dans tous les cas maintenir un fork de pandoc était une plaie. Je suis pas pro de haskell et ils cassent régulièrement des trucs en plein milieu. J'ai fini par laisser tomber cette idée.
Entre temps des bugs et demandes ce sont accumulés sur le zmarkdown. Le soucis avec ce dernier est qu'il est effectivement fait que pour produire du HTML. Il n'a pas d'AST. C'est pour ça que j'étais parti sur pandoc, ça semblait plus simple comme base. Mais au bout du compte :
La solution pragmatique choisi à donc été de repartir sur zmarkdown. La j'ai fini de couvrir et tester nos extensions. Je vais finir de régler une pr et après je continue à faire le ménage (=virer tout ce dont on a pas besoin). L'objectif est d'avoir une base de code plus simple et clean, on a pas besoin de traîner des tonnes de choses qu'on utilise pas.
Une fois cela fait (dans les semaines qui viennent), il faut en rediscuter. Une première suite est de voir si la communauté voudrais pas quelques ajouts. Il y a eu peu d'ajout pendant longtemps. Ça peut être l'occasion de rajouter des bricoles.
La deuxième vrai suite est de changer profondément le coeur pour passer par une vrai AST intermédiaire plutot que la génération quasi direct du html par le zmardown actuel. Ça représente un peu de boulot car ça demande de toucher à tout, dur de le faire par étape. Mais je pense avoir une idée pour régler le point et le faire de façon incrémentale ! (beaucoup plus safe vu que je suis seul sur le projet et que mes dispos sont fluctuantes).
Une fois qu'on aura une vrai AST, tout est possible. Il reste du boulot pour arriver à la génération d'ebook/pdf car il faut remonter d'un niveau et assembler plusieurs extraits pour faire un contenu. Mais ça sera beaucoup plus facile et sûrs de le faire avec des AST. Une fois qu'on a une AST complète, générer des ebook sera assez facile. Pour les pdf, il va falloir faire des essais. Il y a deux grosses pistes :
Utiliser un CSS dédié à l'impression et utiliser quelque chose comme weasyprint :
Générer du Latex. Si on a une AST, c'est pas spécialement compliqué. Là on reviendra aux problèmes que j'avais, c'est a dire faire des rendu correct et sans erreurs de contenus complexes.
Il y a quelques autres détails mais c'est pas très important.
NB: Passer vers sphinx sera probablement assez facile une fois qu'on a une AST mais :
Voila où on en est et où je compte aller. Je suis preneur de toute aide !
Hésite pas à me poser d'autres question ici ou en MP, et de me contacter si tu veux aider !
Merci pour ces nombreuses précisions, je pense quand même continuer la lecture de la ZEP5 pour comprendre les évolutions menées.
Concernant l'AST, je vois qu'il avait été envisagé de générer un document XML et de procéder par transformations XSLT, j'imagine que ça n'est plus d'actualité ?
Je vais d'abord me plonger dans le code et voir comment s'agence le tout (j'ai déjà utilisé et étendu Python-Markdown, mais je ne me suis jamais intéressé de plus près au moteur).
Sur quels sujets aurais-tu besoin d'aide ?
Le xml c'était une suggestion mais c'est comme tout, on a pas vraiment de ressources de dev pour ça. Python reste le plus pragmatique.
Concernant le reste, tu peux effectivement regarder le code. Hésite pas à faire des commentaires ou des pr, je suis le seul à y toucher donc un avis extérieur sera fortement le bienvenu.
Sinon pour l'aide, je vais y réfléchir, jusque là j'avais pas envisagé etre deux, hésite pas à proposer !
Pour t'aider sur le fonctionnement : globalement le traitement se passe actuellement en 4,5 étapes :
Tous les éléments de la syntaxe viennent de ces éléments. Dans l'idéal il n'y aurait pas de pré process ni de post process et une ast généré avant de produire le HTML.
On causait ce soir sur IRC de markdown, de sphinx, donc aussi de rst, et le tout pour en sortir des PDFs. J’ai donc creusé grace à notre nouveau moteur de recherche et suis tombé sur ce topic.
Si faire un énorme refactoring de zmarkdown pour y passer par un AST est toujours d’actualité, ce serait pas mal de se baser par exemple sur mdast. 
Je regarderai à l’occasion. Après en ce moment je travail plus beaucoup dessus. Le weekend dernier j’ai changé le nom du package, je devrais pouvoir le publier sur pip normalement
Hop, je viens de lire un article qui me semble pertinent : https://githubengineering.com/a-formal-spec-for-github-markdown/
Oui j’imagine que si on changeait de parseur il faudrait se baser sur common mark, mais ces derniers temps j’ai pas beaucoup le temps de m’occuper d’un chantier comme ça…
J’vais un peu sortir de ma torpeur pour dire ceci : "oui, mais …" s'en va en courant
Plus sérieusement, ce doter d’un AST, c’est bien. C’est même génial et je suis sincèrement en admiration devant Kje. Mais il se trouve qu’on a choisi un format de Markdown qui n’est pas le "bon" (comprendre "qui n’est pas commonmark") et du coup, on se retrouve coincé. Si on fork un outil existant, il faudra forcément l’adapter à notre syntaxe (au niveau des tableaux, par exemple, partie qui n’est justement pas marrante à coder). Si on s’en "inspire", même histoire, à ceci de différent qu’il faudrait repartir de "rien". J’entend bien qu’on peu s’en sortir avec des plugins, mais le problème reste fondamentalement le même.
Pourquoi on est coincé ? Parce que c’est un choix qui aurait du être fait au début, et qui n’as pas été fait pour de très bonnes raisons (l’existence de pyMarkdown à cette époque, l’absence de connaissance, toussa). Aujourd’hui, on a une masse de trucs écrits en zMd qui est inconvertissable (ne serait-ce que les messages, passe encore, mais il y a les contenus!), et y’a peu de chance que ce soit amené à changer dans le futur (je vois déjà d’ici le bazar que ce serait de mettre un booléen "nouveau markdown" quelque part, même si ça ferait le taff pour les messages).
Du coup, il va falloir qu’on fasse avec, sauf si quelqu’un a une meilleure idée
Pourquoi est-ce que les anciens contenus (tutos, articles et messages) sont impossibles à convertir en commonmark ?
J’ai pas du tout compris ton message, pierre_24.
Petite précision: quand on on a créé zds, common mark n’existait pas !
Très sincèrement, ces derniers temps, je ne fais pas grand chose sur le markdown, juste de temps en temps je fais de la maintenance. Il nous faudrait un markdown avec une ast pour pouvoir bien avancer. On peut modifier l’actuel ou prendre un autre et rajouter nos extensions. Techniquement on a pas mal de tests maintenant, on pourrait envisager changer de parseur et essayer de minimiser les différences (et éventuellement récupérer du contenu de zds pour bien mettre en évidence toutes les différences). Mais dans tous les cas il y a du boulot. Perso j’ai pas beaucoup de temps en ce moment mais bon je ne déserpere pas.
Il me semble qu’on est d’accord, oui ! Pour résumer
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
