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

a marqué ce sujet comme résolu.

J'ai le même ressenti que Dominus sur ce thread, il y a de la mauvaise foi dans l'air…

Perso je suis pro markdown et vu que notre éditeur supporte pas les tabulations le rest risque d'etre pénible, mais sortis de ça c'est pas la mer a boire non plus (bon leur syntaxe est pourri des qu'il y a des liens par contre…)

Après sorti de ça le problème dit et répété par Kje n'est pas la syntaxe d'entrée mais tout les cas alakon galère a sortir proprement (tableau …)

+0 -0

Bon je viens de réagir à UN gros défaut de la solution "moteur CSS" pour générer un pdf : les équations. Il y a plusieurs solutions mais globalement ça va générer des images et donc ça s’intégrera probablement mal au texte.

Entre devoir mettre un mathjax coté serveur ou utiliser latex, je sais pas ce qui est pire :-°

J'ai 94 432 messages dans utils_comment rédigés par 1 570 auteurs différents.

Requête type :

1
2
3
4
5
6
7
8
9
SELECT 
    COUNT(*),
    COUNT(*) * 100 / 94432,
    COUNT(DISTINCT author_id),
    COUNT(DISTINCT author_id) * 100 / 1570
FROM
    utils_comment
WHERE
    text_html LIKE '%<strong>%';

Résultats en reprenant les fonctionnalités du tuto du markdown. Trié par indice, donc par % messages * % auteurs (pour garder un nombre lisible, l'indice vaut 10 - log((messages / 94432) * (auteurs / 1570))).

Fonctionnalité Motif Messages % messages Auteurs % auteurs Indice
Smileys src="/static/smileys/ 31 484 33,34 % 1 041 66,30 % 9,34
Lien <a href= 23 489 24,87 % 1 028 65,48 % 9,21
Citation <blockquote> 21 266 22,52 % 729 46,43 % 9,02
Italique <em> 8 831 9,35 % 545 34,71 % 8,51
Gras <strong> 6 793 7,19 % 616 39,32 % 8,45
Liste à puces <ul> 6 500 6,88 % 589 37,52 % 8,41
Bloc de code <pre> (ou codehilite) 4 052 4,29 % 569 36,24 % 8,19
Image src="http et texte source contient ![ 3 411 3,61 % 522 33,24 % 8,08
Code en ligne <code> 5 250 5,56 % 336 21,40 % 8,08
Ligne de séparation <hr> 1 882 1,99 % 221 14,08 % 7,45
Liste numérotée <ol> 1 450 1,53 % 238 15,16 % 7,37
Spoilers class="spoiler 1 193 1,26 % 278 17,70 % 7,35
Titre de niveau 1 <h3> (sisi) 1 009 1,07 % 249 15,86 % 7,23
Barré <em> 767 0,81 % 216 13,75 % 7,05
Titre de niveau 2 <h4> (idem) 775 0,82 % 205 13,06 % 7,03
Formule mathématique <mathjax> (si !) 1 043 1,10 % 152 9,68 % 7,03
Notes de fin footnote-ref 624 0,66 % 106 6,75 % 6,65
Bloc « Information » class="information 370 0,39 % 131 8,34 % 6,51
Tableau <table> 412 0,43 % 113 7,19 % 6,50
Vidéos <iframe 396 0,42 % 111 7,07 % 6,47
Exposant <sup> 364 0,38 % 120 7,64 % 6,47
Touches <kbd> 330 0,35 % 113 7,19 % 6,40
Indice <sub> 303 0,33 % 88 5,61 % 6,25
Titre de niveau 3 <h5> (idem) 227 0,24 % 104 6,62 % 6,20
Abréviation <abbr 299 0,32 % 75 4,77 % 6,18
Bloc « Question » class="question 283 0,30 % 72 4,59 % 6,14
Bloc « Attention » class="warning 238 0,25 % 84 5,35 % 6,13
Titre de niveau 4 <h6> (idem) 68 0,07 % 49 3,12 % 5,35
Bloc « Erreur » class="error 71 0,08 % 28 1,78 % 5,13
Surlignage dans un code class="hll" 37 0,04 % 21 1,24 % 4,72
Commentaires <--COMMENT 8 0,01 % 4 0,25 % 3,33
^(;,;)^ ^(;,;)^ 4 0,00 % 2 0,13 % 2,73

Ancienne version (premier édit mentionné dans la suite) :

Trié par utilisation, en nombre moyen de messages où l'on trouve la fonctionnalité par auteur utilisant cette fonctionnalité.

Fonctionnalité Motif Messages % messages Auteurs % auteurs Utilisation
Smileys src="/static/smileys/ 31484 33,34% 1041 66,30% 30,24
Citation <blockquote> 21266 22,52% 729 46,43% 29,17
Lien <a href= 23489 24,87% 1028 65,48% 22,85
Italique <em> 8831 9,35% 545 34,71% 16,20
Code en ligne <code> 5250 5,56% 336 21,40% 15,63
Liste à puces <ul> 6500 6,88% 589 37,52% 11,04
Gras <strong> 6793 7,19% 616 39,32% 11,03
Ligne de séparation <hr> 1882 1,99% 221 14,08% 8,52
Bloc de code <pre> (ou codehilite) 4052 4,29% 569 36,24% 7,12
Formule mathématique <mathjax> (si !) 1043 1,10% 152 9,68% 6,86
Image src="http et texte source contient ![ 3411 3,61% 522 33,24% 6,53
Liste numérotée <ol> 1450 1,53% 238 15,16% 6,09
Notes de fin footnote-ref 624 0,66% 106 6,75% 5,89
Spoilers class="spoiler 1193 1,26% 278 17,70% 4,29
Titre de niveau 1 <h3> (sisi) 1009 1,07% 249 15,86% 4,05
Abréviation <abbr 299 0,32% 75 4,77% 3,99
Bloc « Question » class="question 283 0,30% 72 4,59% 3,93
Titre de niveau 2 <h4> (idem) 775 0,82% 205 13,06% 3,78
Tableau <table> 412 0,43% 113 7,19% 3,65
Vidéos <iframe 396 0,42% 111 7,07% 3,57
Barré <em> 767 0,81% 216 13,75% 3,55
Indice <sub> 303 0,33% 88 5,61% 3,44
Exposant <sup> 364 0,38% 120 7,64% 3,03
Touches <kbd> 330 0,35% 113 7,19% 2,92
Bloc « Attention » class="warning 238 0,25% 84 5,35% 2,83
Bloc « Information » class="information 370 0,39% 131 8,34% 2,82
Bloc « Erreur » class="error 71 0,08% 28 1,78% 2,54
Titre de niveau 3 <h5> (idem) 227 0,24% 104 6,62% 2,18
Commentaires <--COMMENT 8 0,01% 4 0,25% 2,00
^(;,;)^ ^(;,;)^ 4 0,00% 2 0,13% 2,00
Surlignage dans un code class="hll" 37 0,04% 21 1,24% 1,76
Titre de niveau 4 <h6> (idem) 68 0,07% 49 3,12% 1,39

C’est pas mal comme ordonnancement. En sélectionnant ce qui a une utilisation de 4 ou plus, on a un Top 15 des fonctionnalités les plus utilisées, et une séparation nette entre les fonctionnalités apparaissant dans plus ou moins de 1 % des messages.

EDIT : à l’exception des notes de fin, pardon, j’avais mal lu.

+0 -0

À défaut de servir à quelque chose, c'est intéressant.

Bon je ne sais pas ce que je/on doit faire.

Je peux tenter de reprendre le code que j'avais commencé pour génerer quelques articles. Vous verrez ce que ça donne et ça donnera des exemples de latex qui posent problème

Il se pourrait que la limitation des tabulations saute dans un avenir proche. ^^

J'ai aussi implémenté le Tab pour indenter. Si on est dans une liste, ça indente la ligne courante/sélectionnée de 2 ; sinon de 4. Si on est pas dans une liste, et avec rien de sélectionné, ça va faire une indentation "intelligente" qu'on retrouve dans la plupart des éditeurs, qui va rajouter 1 à 4 espaces, pour qu'on soit toujours aligné sur les "colonnes de tabulations" (aucune idée de comment on peut appeler ça, mais je pense que vous avez compris le principe c: ). Avec le Tab vient forcément le Shift-Tab pour désindenter.

Sandhose

+0 -1

Bon on pourrait arrêter ce sujet ? Si vous voulez vraiment changer le markdown par autre chose, c'est pas ici que la question doit être débattu.

Le problème ici est "comment générer des pdf propre" depuis le markdown (mais techniquement on risque d'avoir les même problèmes avec ReST). C'est ce problème qui conditionne tout le reste.

Je vois deux grandes façon de faire :

  • Le générer depuis le HTML directement :

    • Avantages: C'est une pipeline bien linéaire "md -> html -> pdf". Les technos web (css) doivent permettre d'avoir un rendu propre. On aurait un truc en "full-python".
    • Désavantages: Comment rendre les formules de math proprement ?
  • Générer du latex et le compiler :

    • Avantages: On a déjà des bases de codes pour ça. Le rendu est très propre en général.
    • Désavantages : Les structures complexes en Latex sont compliqués à gérer sur un truc automatique. Ça fait des dépendances très lourdes (latex, pandoc probablement, etc.).

Je suis vraiment partagé sur cette question. La première solution est celle qui me plait le mieux en terme de simplicité. Plus simple à développer, maintenir et faire évoluer. Mais les balises de maths étant assez rependu dans nos articles et cours, si on peut pas garantir un rendu propre…

La deuxième est probablement la plus complète. Une fois que la base sera là il serait probablement pas trop compliqué d'ajouter des langages d'entrées (au moins en import) et de sorties. Le rendu latex est propre. Mais ça demande de la maîtrise en latex, haskell, plus de code à maintenir et une chaîne "lourde" à gérer.

A court terme, peut être ce soir, je vais tenter de remettre en route ce que j'avais commencé pour vous donner des exemples de latex/pdf qui me posaient problèmes.

Personnellement, je tablerais sur la première solution, en ayant une réflexion à part sur la question des maths, qui posent de toute manière un problème dans la version affichée sur le site (MathJax est vraiment trop lourd). J’avais fait pas mal de recherches et d’essais sur la question, mais il me faut un peu de temps pour présenter ça sous une forme compréhensible. :)

+0 -0

Personnellement je ne suis pas très fan de la solution 1. Je ne peux m'empêcher de penser que se priver de LateX est passer à coté de plein de bonne chose. Mais je n'irai pas non plus jusqu'à dire qu'il faut transformer notre markdown en LateX nous même. Voici comment je verrais les choses :

  • A partir d'un contenu en markdown comme celui-ci par exemple :

1
2
3
4
5
6
Bonjour cher **ami**,

[[q]]
| Qui est ton ami ?

Bonne question.

  • Pour le site, le Html/Css est produit comme aujourd'hui à l'aide de Python-Markdown, ce qui donne un rendu tel qu'on le connait et qui tourne.

  • Pour les pdfs, on développe qui transforme notre zMarkdown en Markdown+LateX. C'est à dire que nos extensions que pandoc ne connait pas (elles ne sont pas si nombreuses) sont transformées en balises LateX directement. ça donnerait (pour notre cas ci-dessus) le markdown suivant :

1
2
3
4
5
6
7
Bonjour cher **ami**,

\begin{block}{Question}
Qui est ton ami ?
\end{block}

Bonne question.

Donner le document ci-dessous à pandoc permet d'avoir un pdf presque correct.


ça nous évite de devoir forker pandoc (visiblement on a pas beaucoup de ressources pour ça) et l'idée est de développer juste ce wrapper (intégrable à python-markdown en plus) qui peut être fait en python (pour lequel on a déjà plus de ressources de dev). On n'a donc pas besoin de générer du LateX complet, juste se concentrer sur ce que pandoc ne comprend pas.

en image ça donne ceci.

workflow

En orangé on a le seul truc à développer (le reste on le garde tout tel quel). Et on peut le faire de manière progressive. Et on plus serein pour la compilation LateX vu que le document reste en grande partie du markdown.

Je suis totalement contre ta solution.

Déjà parce que ce n'est PAS rajouter notre syntaxe dans pandoc le plus compliqué. Ce qui pose problème c'est quand tu as des constructions complexes en latex. Typiquement du code inline dans un bloc info dans un tableau (je caricature mais c'est l'idée). Le problème est alors de trouver comment le latex doit être écrit pour que ça compile correctement.

Ta solution ne règle pas ce problème et pourtant c'est le plus important. Et, surtout, aller mélanger le latex et le markdown c'est l'ouverture à plein de problème :

  • Que ce passe-t'il si l'auteur avait écrit du latex en dehors de balise code ?
  • Que ce passe-t'il lorsque tu as des constructions imbriqué ?

Je ne vois que des désavantages à ta solution sans résoudre le problème initial.

Ce qui me fait pencher vers cette solution c'est principalement :

  • Eviter de maintenir un fork de pandoc (je n'ai pas l'impression que ce soit la tasse de thé de nos devs réguliers ni de notre communauté)
  • Minimiser l'interaction avec LateX (le wrapper évite de devoir recoder pandoc avec les outils qu'on maitrise le mieux ), ce qui permet plus simplement de résoudre les problèmes de compilation LateX. Je ne suis pas un pro de LateX, mais j'ai une pile de documents assez complexes qui allient Markdown + LateX + pandoc et dans la grosse majorité des cas, je trouve très vite d'ou vient le problème comparé à si le document était full LateX
  • Débloquer cette ZEP qui traine depuis trop longtemps.

Si j'ai bien compris ce que dis Kje, ce qu'il a fait déjà fonctionne pour les 90% des contenus, pourquoi est-ce qu'on ne pousse déjà pas ça en résolvant de manière progressive les problème LateX sur les 10% restant. Et je reste convaincu que s'affranchir d'un fork de pandoc ne peut être que bénéfique sur le moyen terme.

Mélanger latex est pour moi une très mauvaise idée : gérer du latex seul est déjà problématique alors pas besoin de rajouter des cas où ils vont entrer en conflit.

De plus ta solution nous rajoute une couche de langage intermédiaire ce qui est ce qu'on cherche à éviter.

J'en reviens pour le moment a ma proposition de ce matin : vous sortir les latex et pdf qui me posent problème et on verra

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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