Rédaction scientifique

@Dominus Carnufex : je suis globalement contre recoder un truc pour faire ça. Pour plusieurs raisons,la principale étant qu'on a pas les ressources en terme de dev de maintenir ce qui ne serait qu'un fork dans un autre langage de mathjax. Si on veut faire ça côté serveur, on appellera mathjax directement. Cependant on perd alors, dans la génération que tu propose, toutes les fonctionnalités proposés par mathjax côté client accessible par le clic droit.

Apparemment, la version que l'on appelle de MathJax charge dynamiquement d'autres modules d'on elle a besoin. Ce qui fait sûrement une perte de temps.

Il existe une version, plus lourde, qui contient tout (à ce qu'il parait il suffit de rajouter "-full" à l'url). Le premier temps de chargement serait plus long mais normalement le fichier sera mis en cache et on pourrait possiblement gagner en temps.

Ou sinon, on peut faire en sorte que le navigateur charge MathJax plus tôt mais le chargement global de la page risque d'être ralenti.

Voir la documentation de MathJax

Ou sinon, on peut faire en sorte que le navigateur charge MathJax plus tôt mais le chargement global de la page risque d'être ralenti.

A noter que dans un tel cas le markdown peut très bien indiquer si un message/extrait contient des forumles math ou non. En le mémorisant le back pourrait combiner les infos pour inclure mathjax, ou non, en fonction des besoins.

Petit supplément d'information. Je viens de faire un essai avec les trois formule suivantes répétées 10 fois pour commencer à mettre Mathjax en difficulté.

$$\mathbb Z\times\mathbb N \to \mathbb Q$$

$$\begin{array}{c | c c} x & \cos x & \sin x \\ \hline 0 & 1 & 0 \\ \pi/2 & 0 & 1 \\ \pi & -1 & 0 \end{array}$$

$$\frac{\sqrt[13]{\frac{128 \cdot x^{\frac 79}}{\sqrt[11]{3i}}}}{\sum_{x=e^4}^{e^{\frac 35}} \left[ \frac xn \right]}$$

Avec la configuration actuelle (HTML CSS), ce simple petit bout de code met environ 13 secondes à s'afficher correctement. Si je bascule vers l'interpréteur de MathMl intégré à mon navigateur (config MathMl), il faut 3 grosses secondes pour que l'affichage se fasse correctement. Ce n'est pas encore parfait, mais le gain de temps est notable. En outre, malgré la complexité de la formule représentée, il n'y a aucune erreur de rendu.

Ce serait donc intéressant de voir si le résultat est aussi efficace dans les autres navigateurs, pour éventuellement faite de a config MathML la config par défaut.

Debian/Jessie et Chrome/41.0, pas de support du MathML. Fait ch*** !!

Il existe forcément un moyen de faire un fallback en cas de non support !

Oui de ce que j'ai lu il n'y a que gecko qui a un support correct de mathml. Celui de webkit a de très sérieuses limitation et problèmes et Google a carrément viré le support fans chrome.

Et on ne peut pas imaginer pouvoir proposer par défaut un pdf ?

Histoire d'avoir quelque chose d'un peu plus propre de mis en avant en attendant. C'est tet pas dans l'esprit du site, mais on peut pas nier que si on passait à du LaTeX on gagnerait beaucoup en confort de lecture, même si on perd l'inclusion de vidéos/gifs (ce qui n'est pas super important en sciences, si?).

(Je fais me faire taper dessus, c'est prévu)

L'export pdf fonctionne mal car, en gros, notre syntaxe de markdown n'est pas géré. La bonne nouvelle c'est que ça doit être amélioré par la zep-5 et on a déjà un prototype de pandoc capable de comprendre toute notre syntaxe pour la génération de pdf via latex. La mauvaise nouvelle est que c'est un peu en pause parce que la stylisation de nos éléments pose des problèmes de compilation latex dans des corners cases (genre des codes dans des spoiler ou info). L'autre bonne nouvelle est que je suis justement dessus en ce moment même.

Fiou, c'est une montagne-russe émotionnelle :0

Est-ce que ça serait possible alors que je fasse moi même le pdf et que je le mette ? Ou alors je suis obligé de respecter la charte graphique ?

Et on ne peut pas imaginer pouvoir proposer par défaut un pdf ?

Sous forme de lien ? A la place ou en complément du texte en ligne. J'ai pas vraiment compris ce que tu penses…

proposer un pdf perso plutôt que celui gnéré par zds.

Ah OK. Dans ce cas là je pense que c'est possible que tu mettes un lien dans l'introduction (à voir avec les validos). Après, pouvoir proposer un pdf à la place de l'actuel, je ne suis pas très pour…

moi non plus, je vois ça comme une faille de sécurité potentielle assez forte.

Oui tu peux. Ça a déjà été fait pour l'article sur le C++14 en fait. Retrouve le, tu verras il y a un lien en intro.

Si je puis me permettre, c'est une bonne chose que tu travailles à améliorer le rendu en PDF, mais il ne faut pas oublier que la génération automatique directement en PDF n'est qu'un pis aller. Il y a toutes sortes de choses qui ont du sens dans une présentation de type page Web qui n'en ont plus aucun dans un structure figée et paginée comme celle d'un PDF. Exemples parmi d'autres.

• Une balise « spoiler » n'a rien à faire dans un PDF. S'il s'agit de cacher la réponse (en quelques mots/phrases) d'un exercice ou d'une devinette, on va faire une note de bas de page, voire une note de fin. S'il s'agit de masquer tout un code source ou autre document qui prend beaucoup de place et n'est pas essentiel à la compréhension, on va le mettre en annexe à la fin du chapitre voire du livre.
• Le format « livre » peut être l'occasion d'introduire un peu de raffinement, comme une distinction entre notes de bas de page et notes de fin. De générer des tables des matières / des illustrations / des tableaux plus intelligentes que celles utilisées sur le Web. Et des index. Etc.
• La gestion des images est terriblement limitée avec le markdown : impossible de mettre deux images de type bloc côte-à-côte, si on aligne à droite ou à gauche, il y a un gros blanc dans le texte, etc. Du coup, les images sont placées comme coupures dans le texte. Mais lors de la pagination, ces images sont fort susceptibles de se retrouver à cheval sur deux pages, générant l'horrifique « blanc de l'image mal placée ».
• Certaines personnes utilisent la balise <hr /> pour séparer des unités de contenu, mais dans un livre, on utilisera généralement des astérisques ou une image spécifique.
• Je suis sûr que je peux en trouver d'autres. Et tout cela n'est pas une simple question de stylisation du HTML+CSS existant, il faut réellement le remanier.

Tout ça pour dire qu'un PDF généré automatiquement aura quasiment toujours un rendu moche, parce qu'il faut une part d'intervention humaine pour en faire quelque chose d'acceptable. Donc à mon sens, ce n'est pas tant le rendu automatique en PDF qui est prioritaire, que la possibilité pour l'auteur d'exporter son tuto en ODF (très proche du HTML, ce qui doit simplifier les choses) ou en LaTeX selon les goûts, puis d'importer le PDF (voire le ODF en lecture seule) retravaillé qui sera alors disponible au téléchargement pour tout le monde.

Ce qui touche aussi à notre question, parce que pour faire un export propre d'un tuto de maths en ODF, il faut convertir les formules en MathML, quel que soit le moyen employé.

Je ne suis pas vraiment d'accord, dans le sens où ce que tu dis là est vrai (modulo le fait qu'il faudrait distinguer PDF pour lecture à l'écran et PDF pour l'impression).

Par contre, tu supposes que les auteurs sont prêts à préparer eux-même un PDF en respect de tout ce que tu indique. C'est doublement faux, premièrement parce que la majorité des auteurs n'ont ni les connaissances, ni le temps pour ce faire ; deuxièmement parce que ça n'intéresse pas forcément les auteurs de s'atteler à ce genre de problème. En est témoin la génération de PDF qui passe parfois mal et le très faible taux de plaintes qu'on à eues à ce sujet.

Donc, pour moi la priorité est belle est bien d'avoir la meilleure gestion automatique des PDF (et des formats pour liseuses) possible, parce qu'il n'y a que par ce moyen qu'on aura quelque chose d'acceptable sur tous les tutos.

Bon alors l'export pdf c'est en réalité la première étape dans la rationalisation des outils markdowns du site. Il ne sera pas parfait, certes, mais ce sera déjà largement mieux qu'un export depuis une page web. Le passage par latex offrant déjà un rendu respectable. Ensuite certaines sémantiques sont déjà adaptés dans la version en dev. Par exemple :

• Les abréviations sont regroupés dans une liste de définition dans une section non-numéroté en début de document.
• les liens sont actifs mais présentent en plus une note de bas de page avec l'adresse.
• Les vidéos proposent une image aperçus + l'adresse de la vidéo.
• les spoiler il est prévu de les transformer en note de fin de document.

etc.

On a fait le choix d'avoir un markdown assez sémantique, plutot que lié au style, du coup on va adapter le rendu au format.

Évidement ce ne sera pas parfait. La latex pourra être fournit très facilement. D'autres formats pourront être proposés (facilement tous ceux supportés par pandoc en sortie) mais ce n'est pas la priorité.

Certains de tes exemples peuvent être aussi adapté. Les hr peuvent être personnalisés si on le souhaite. Pour les images, la solution est plutot d'ajouter des sémantiques pour coller plusieurs images dans les figures.

Mais bon, il faut être conscient que 90% des auteurs n'ont pas envie de passer du temps sur la personnalisation des pdf. Un export automatique des pdf, même pas idéal, est déjà important. Et encore une fois c'est le premier pas vers la refonte du markdown qui permettra d'avoir un seul outil pour tout et proposer les différents exports que tu demande.

@Spacefox : Je suis d'accord que nombre d'auteurs n'en ont rien à cirer d'avoir un export en PDF qui ressemble à quelque chose. Seulement, ton raisonnement se mord aussi un peu la queue : si je ne ne me suis jamais plaint de l'export en PDF, c'est qu'il est tellement merdique que je ne cherche même pas à m'en servir. Pas parce qu'il ne m'intéresse pas.

Seulement, ton raisonnement se mord aussi un peu la queue : si je ne ne me suis jamais plaint de l'export en PDF, c'est qu'il est tellement merdique que je ne cherche même pas à m'en servir. Pas parce qu'il ne m'intéresse pas.

Si tu ne signales pas que tu considères le rendu merdique, comment veux-tu qu'on le devine ?