Rédaction scientifique

Je ne peux que vivement t'encourager

Je trouve que ça prend de la place, je prefère l'idée d'un tableau dynamique du style referré comme :

1
2
3

*[E]: Energie
*[m]: masse de l'objet
*[c]: célérité de la lumière

Et après lorsqu'on écrit une équation, le système lirais notre équation, déterminerais de gauche à droite les termes qui apparraissent, et les restituerais dans un bloc au survole.

Imaginons que j'ai fais ce code sur un de mes postes en physique :

1
2
3
4
5
6
7
8

*[p]: ordre d’interférence 
*[\delta]: différence de marche
*[\lambda]: longueur d'onde
*[a]: pas des fentes
*[x_1]: position de la frange p=0
*[D]: distance fentes-écran
*[e]: épaisseur de la lame
*[n]: indice de la lame

Et qu'ensuite j'écrive une équation;

Le problème est que le markdown ne parse pas le latex. Ce que tu propose impose d'être capable de parser les formules, pour extraire les termes cités.

Donc dès qu'on met '$ le markdown ne peux pas pénétrer ?

En soit, si il pourrait. Mais pour Faure correctement le travail il faudrait parser le latex a l'intérieur pour extraire les expression utilisé et, honnêtement, j'ai la flemme de rajouter un parseur de latex dans le markdown

Je suis vraiment pas fan de cette solution pour plusieurs raisons :

• les notations ne sont pas utilisées que dans les équations ;
• c'est très lourd à chaque lecture pour peu qu'on balade la souris ;
• on en a pas tout le temps besoin et partout, l'avoir au début permet de savoir que c'est là et de pouvoir le lire quand on veut.

Dans les rédactions scientifiques c'est généralement la coutume : au début ou à la fin on met un tel tableau (même si ça prend une page) et avec même une référence vers la présentation de la notation (vers la définition).

C'est peut-être un peu HS, mais s'il y a une refonte de l'outil de formule, y aurait-il moyen de le rendre moins lent à l'affichage ? Si je prends par exemple le tuto en bêta de Holosmos, le simple fait d'afficher la page me prend un processeur, même une fois la page chargée. De plus le défilement au sein de la page est vraiment lent (touches ⇞). Ça rend la lecture assez difficile.

So true, imagine ma souffrance pendant la rédaction !

D'ailleurs je peux pas faire plusieurs page pour mon mini-tuto ? Obligé que ça soit un big pour ça? Parce que pour le coup ça réduirait la consommation en uranium de faire plusieurs pages.

C'est peut-être un peu HS, mais s'il y a une refonte de l'outil de formule, y aurait-il moyen de le rendre moins lent à l'affichage ?

Je ne pense pas mais je vais quand même me renseigner !

Je pense que la meilleure solution pour changer ça serait de remplacer mathjax. Mais le remplacer par quoi ?

D'ailleurs je peux pas faire plusieurs page pour mon mini-tuto ? Obligé que ça soit un big pour ça? Parce que pour le coup ça réduirait la consommation en uranium de faire plusieurs pages.

En cours d'implémentation dans la zep12. Si j'ai un peu de temps cette semaine je fais un exemple.

Je ne serais pas si radical (venant de moi .. Prenez un screen). Il n'y a pas moyen de paramétrer les calculs de mise en page ? Déjà on pourrait retirer la modification sur la taille de police. De ce que je vois ça demande pas mal de calcul puisque je vois s'afficher d'abord une version non agrandie et plusieurs secondes après une version agrandie.

Je ne dis pas la contraire. Pour la taille de police c'est, je pense, qu'une question de configuration de mathjax mais encore faut il que quelqu'un se décide à se pencher dessus. Cependant il faut bien être conscient que certains des défauts que vous listés, entre autre le temps de transformation lent, ne peut pas vraiment être réglé. Mathjax est une lib js chargé au niveau de la page qui va parcourir, en JS, le dom pour trouver les équations qu'il doit transformer et génère alors l'aperçu correspondant coté client. Avec un tel système, toutes pages avec pleins d'équations prendra forcément un certain temps à être mise à jour et il est impossible de vraiment influencer dessus. C'est je pense le gros défaut de mathjax, tout se passe coté client et on peut difficilement le maîtriser.

Techniquement il est assez facile de changer le système de génération d'équation. Si vous trouvez une lib mieux (coté client ou coté serveur), on peut envisager un changement. Mais autant la taille de police ça peut être facile, autant le temps de génération on peut pas y faire grand chose.

Comment fait wikipedia? Il me semble que les formules sont pré-générées et que rien n'est calculé a l'affichage. C'était aussi le système sur l'ancienne version du sdz il me semble.

C'est tout à fait subjectif, mais j'aime pas le système wikipedia/feu SdZ. Alors ok, on gagne en temps de chargement (quoique, sur l'ancien SdZ, pas tant que ça parce que rien était foutu en cache, trust me on this), mais on perd en aliasing, en possibilité de copier/coller et en simplicité de manipulation. D'autant que comme dit Kje, on ne peut rien y faire (objectivement, quelqu'un a une idée autre que les images ?).

EDIT: la taille de la police, c'est même plus simple qu'une question de configuration, c'est du CSS. Je pense ceci dit qu'il n'y aie pas moyen de faire la différence entre du code inline et bloc (à vérifier)

RE-EDIT: puis, soyons réaliste, le web n'est absolument pas adapté à la rédaction d'articles scientifiques de haut vols (je viens de me faire des enemis en disant ça). Je vais parler de ce que je connais, mais même les articles en lignes des journaux de chimie ne sont pas justifiés, c'est pour dire.

EDIT: la taille de la police, c'est même plus simple qu'une question de configuration, c'est du CSS. Je pense ceci dit qu'il n'y aie pas moyen de faire la différence entre du code inline et bloc (à vérifier)

Oui et non. Mathjax controle lui même le rendu et peut donc très bien surchargé la taille de la police quand il les transforme.

Concernant la différence inline/bloc, cette distinction est bien comprise par mathjax. Ils ont cette notion donc je ne vois pas de raisons pour que tu ne puisse pas les régler différemment.

Le site "Khan accademy" a sorti KaTeX qui propose une alternative à mathjax et qui règle une partie des problèmes évoqués ci-dessus. Cependant le support de latex est loin d'être aussi complet que celui de mathjax et sur leur site Khan accademy utilise encore les deux (KaTeX quand il est capable de faire le travail, mathjax quand il n'y arrive pas). Je ne vous cache pas que je suis relativement perplexe sur utiliser un tel système pour zds. Maintenir la gestion de deux libs pour la même chose, c'est trop de travail pour nos ressources de dev.

Une solution intermédiaire serait de voir si il est possible d'appeler mathjax coté seveur, pour générer du js insérable dans le doc directement. On économiserait alors le parcours du dom et ce serait intégré au cache déjà existant. Cependant ça demande deux choses :

• que quelqu'un regarde si on peut générer ce genre de chose depuis mathjax
• d'avoir un node-js coté serveur pour ça.

Je ne suis pas sûr de comprendre. Au contraire, le gros avantage de wiki, c'est qu'on peut copier-coller les formules directement, ce qu'on ne peut pas faire à partir d'un post de ce forum par exemple.

Sur wikipedia tu as une image, tu peux donc la copier, elle, mais tu ne peux pas récupérer le code latex sous-jacent.

Après tout ça est très subjectif je pense. Pour moi là il y a trois niveaux d'amélioration :

• Facile/Rapide: Quelqu'un qui se penche sur la configuration de mathjax, pour régler l'histoire des polices et optimiser les temps de traitements. Il y a peut etre des options qui permettent d'améliorer les choses.
• Moyen: Regarder si une partie de travail de mathjax ne peut pas être fait coté serveur. Ça peut être de simplement lui pré-identifier les formules à transformer dans le DOM à une génération complète coté serveur. Ça dépend beaucoup du code de mathjax et c'est dans sa doc qu'il faut voir ça. Mais je peux assurer que coté markdown on passe à un moment sur toutes les formules, il est donc possible de lancer une manipulation à ce moment là pour générer quelque chose.
• Dur/Long: Identifier une alternative viable à mathjax. Je considère que c'est la plus dur des tâches car plus que l'implémentation, c'est l'identification des alternatives, l'études de leurs avantages, inconvénients et impact sur nos contenu et, enfin, le débat pour conclure qui va prendre pas mal de temps et d’énergie.

Plusieurs remarques.

Je suis d'accord que la génération directe d'images n'est pas optimale en termes de réutilisation. Cependant, elle apporte un gain de vitesse vraiment appréciable. Donc, en dernier recours…

La différence de taille de police n'est pas toujours gênante. Personnellement, quand je rédige un tuto de maths ou assimilé, j'apprécie que les nombres et lettres mathématiques utilisés directement dans le texte soient assez nettement différents graphiquement du reste de mon texte.

Le rendu de MathJax est configurable. Si vous faites un clic droit sur une zone de maths, un menu apparaît. « Math settings » => « Math renderer » et vous avez alors 4 choix. Le premier, HTML CSS est celui que nous utilisons actuellement. Le second, Fast-HTML est un rendu tout bête, celui qui apparaît dans un premier temps quand la page a du mal à charger. MathML fait appel au générateur de MathML intégré au navigateur : mathJax prévient que ce générateur intégré ne saura pas forcément tout gérer correctement. Dans mon essai (Linux Mint 17, FF 36), il n'y a aucun problème, et le code source généré est beaucoup plus léger que celui de HTML CSS. Enfin, le rendu en SVG est possible.

En d'autres termes, avant d'envisager de changer de solution, il faut déjà explorer les possibilités offertes par MathJax.

Enfin, si vous regardez le code source de ce que génère MathJax, c'est un amoncellement de SPAN avec divers styles, lesquels contiennent de bêtes caractères Unicode. Cela signifie, d'une part, qu'il est tout à fait possible de générer le code en amont et de l'intégrer dans le rendu mis en cache : ce code HTML+CSS étant cependant très très verbeux, il faut vérifier que sa simple interprétation par le navigo ne prend pas des plombes. Cela signifie d'autre part qu'il est envisageable de faire nous même un outil (en python, par exemple, pour ne pas créer de nouvelle dépendance), qui génère le HTML+CSS côté serveur. La solution optimale en termes de fonctionnalités (pas de temps de travail) serait de faire ce générateur en Haskell pour l'intégrer directement au parseur de markdown.

Je faisais référence au "clic droit > Show math as > TeX command" (j'imagine que vous devez l'avoir en français). Puis objectivement, le copier de ces fameuses images dans Word les rends parfaitement dégelasses, en plus du fait qu'il sais pas quoi faire avec l'alignement (et là, t'as des problème de "taille de police" si tu commence à jouer à redimensionner les images).

Si tu ne copies que la formule, tu copies une image. Par contre, si tu copies du texte + la formule, tu obtiens le texte + le code latex (sans les dollars) (quand je le colle dans l'éditeur par exemple, peut-être que sous Word il colle l'image)

Si tu regardes le code source d'une page wiki, tu as un lien vers l'image + le code latex:

<dl>
<dd><img class="mwe-math-fallback-image-inline tex" alt="\int_a^b f(t) dt\," src="//upload.wikimedia.org/math/1/9/3/1937fe75a4991972ccc882b454006d7a.png" /></dd>
</dl> '''