Une alternative à MathJax ?

Bonjour à tous,

Je suis tombé sur KaTex qui se veut une alternative à MathJax. D'après le hollandais volant KaTex est plus rapide et plus léger mais ne supporte pas les anciens navigateurs, gère moins de format et est plus strict sur la syntaxe des équations.

Je pense que ça vaut le coup de faire des recherches plus approfondies et tester KaTex pour voir s'il convient à notre besoin, non ?

Ça mérite un essai, je pense. MathJax est lourd. Même sur des pages pas si chargées, ça ralenti.

Comme alternative possible à tester, il existe également jqmath. Il faudrait également envisager la possibilité de faire la transformation LaTeX → HTML côté serveur, en particulier pour les petites formules. J’ai pas mal de trucs dans les cartons sur le sujet, mais pas le temps de détailler là tout de suite.

Salut,

C'est sûr qu'une alternative légère serait bienvenue, mais il ne faudrait pas que ce soit aux dépends de la flexibilité de l'outil.

Il y a quand même un point noir sur KaTeX, il est impossible de récupérer les commandes LaTeX comme on peut le faire avec MathJax… Il faudrait être sûr de comment ça se comporte pour les malvoyants, aussi.

Pour jqmath, c'est moi, ou le rendu est carrément dégueulasse ?

Pour chacune de ces deux alternatives, est-il possible de rajouter nous-même les modules dont on peut avoir besoin ? Par exemple, il me semble que pierre24 avait ajouté des modules pour l'écriture des équations chimiques.

Pour jqmath, c'est moi, ou le rendu est carrément dégueulasse ?

Les exemples de leur site me paraissent correcte chez moi.

Suffit de regarder 2/3 fichiers du code de KaTex pour voir que c'est tellement plus moderne dans la manière dont c'est fait c:

Aussi, il a l'énorme avantage d'être publié correctement dans npm, et donc on a potentiellement beaucoup plus de contrôle dans process de build, dans la manière dont c'est chargé et tout… Que du positif, donc !

Gros +1 de ma part, donc

Voilà la liste des commandes Tex que KaTex prend en compte.

Il y a quand même un point noir sur KaTeX, il est impossible de récupérer les commandes LaTeX comme on peut le faire avec MathJax…

Euh, c'est-à-dire ?

\aligned, \mathbb et consorts ne sont même pas dans la dernière release si on en croit la note en bas de page. Ça, ça foutrait en l'air pas mal de posts et tuto.

Euh, c'est-à-dire ? 

Pas de moyen de copier-coller facilement une formule. Avec MathJax, on peut faire un clic-droit sur une formule et demander le code LaTeX. Ce n'est pas possible sous aucune façon avec KaTeX. Je trouve ça quand même pas mal handicapant.

EDIT : si ça se fait, faudra bien voir à mettre les mêmes délimiteurs qu'actuellement au lieu des défauts histoire de pas casser toutes les maths.

Pour avoir fait des essais avec katex au boulot, non c'est pas viable car des que les formules sont un peu compliqué il fait un rendu tout pourri.

Je crois que Kahn academy l'utilise mais bascule vers mathjax des que katex ne gère pas bien le truc. C'est un peu usine à gaz

On pourrait déjà faire la MAJ "Si MathJax n'est pas utiliser, on le charge pas" Car de mémoire on le charge sur tous les tutos et pages de forum (sauf si ça a été corrigé)

Ce à quoi on a déjà répondu que techniquement, il était assez difficile de détecter l'usage de LaTeX, justement (faire une regex sur chaque message d'un topic, je pense que ça va être aussi désastreux question performance que faire charger MathJaX, et la discussion tien aussi pour les commentaires d'un tuto/article).

Du reste, Kje, si t'as des exemple de cas ou ça marche pas, ça peu toujours être intéressant (pour voir les limites de l'outil). De manière tout à fait personnelle, j'avais effectivement demandé à activer mhchem, mais c'est documenté nul part, donc je suis probablement le seul à l'employer (et je saurais m'adapter, c'est juste pour "simplifier" la vie).

Par contre, parce que ça a déjà posé problème par le passé, il faut absolument qu'on puisse faire en sorte de ne pas parser certaines zones de la page (ou qu'on puisse lui demander de parser uniquement certaines zones de la page), pour éviter des ennuis (LaTeX dans un titre de post, typiquement). Il est également important de voir comment le package gère \newcommand{}{}, \renewcommand{}{} et \def, qui nous a déjà posé problème (et qui en pose toujours).

Bah déjà MathJax n'est pas autorisé dans les titres et sous-titres donc on peut le désactiver en dehors des sujets, messages privés et contenus ! Ensuite, je pense qu'on peut le rendre optionnel pour ces derniers (avec par exemple une case à cocher) ?

Ensuite, je pense qu'on peut le rendre optionnel pour ces derniers (avec par exemple une case à cocher) ?

Le créateur du sujet ne sais pas à l'avance que les personnes qui vont lui répondre vont utiliser mathjax ou pas a priori…

Ouais, enfin ça reste utilisable pour le tutoriels et articles !

Sauf qu'il faut les charger pour les commentaires… Ça me semble très casse gueule de présupposer les pages où le charger. La vrai façon de faire des économies seraient de les générer coté serveur.

Pourquoi ne pas ajoutée une colonne dans la BDD des comm, tuto, etc. Afin de savoir si le message contient du MathJax.

Et on fait le parsing lors de l'insertion et de la mise a jour d'un post.

C'est bien beau, tout ça, mais ça ne résoudra en rien le problème de MathJax dans les tutos qui mettent des maths. Si je prends mon tuto en exemple, il faut quelques secondes pour le charger correctement, alors qu'il n'y a pas tant de maths que ça dedans.

J'ai déjà vu des problèmes similaires dans des sujets de forums, en particulier quand quelqu'un fait une erreur de syntaxe.

Ce serait vraiment bien d'éviter de se retrouver avec un statu quo. Si ces alternatives sont légères, ne peut-on pas imaginer par exemple permettre à un auteur de tuto de se restreindre à l'une d'elle, ce qui permettrait un affichage confortable de son tuto ?

Édit : c'était l'un des problèmes pointé dans ce sujet.

EDIT: méchamment grillé par Gabbro.

Si vous voulez, mais vous déviez du sujet, là.

Ne pas le charger ne va pas changer grand chose : c'est pas charger MathJaX qui est pénible (puisqu'il est la plupart du temps dans le cache du navigateur, modulo l'équivalent du paramètre max-age dans HTTP), mais le temps incroyable qu'il passe à parser les équations. Pour moi, là, on est sur de la micro-optimisation, et je serai curieux de voir si ça change réellement quelque chose (et pas un machin de 10 ms) de ne pas le charger sur un tuto (par exemple) qui ne contient effectivement pas de mathématiques.

Alors que trouver une alternative (si elle existe) s'attaquera clairement au problème qui est qu'une page qui contient des maths met 20 ans (j'exagère) avant de voir ces maths correctement affichés.

Non ?

On peut effectivement, a priori le markdown est capable de le dire. Perso ça me semble un peu overkill mais bon c'est pas moi qui m'occupe de ça.

Pour les cas problématiques de Katex, je demande a mon collègue qui s'en ai occupé demain et je verrai si il s'en souvient.

En générant les maths côté serveur, on s’épargne le temps d’affichage une fois la page chargée, mais les données à transmettre sont nettement plus lourdes, et il faut voir l’impact que ça aura sur le temps de chargement global. Voici quelques chiffres (en octets) de quand j’avais fait du repérage.

Formule 3 : simple $x$ inline.

Comme vous le voyez, le rendu « HTML+CSS » actuellement utilisé est terriblement lourd, surtout pour les petites formules parsemées un peu partout. Le SVG est sûrement ce qui permet d’être le moins lourd tout en restant compatible partout, mais ça reste plus de 30 fois plus lourd que le système actuel. Un système mixte, avec un parseur maison qui passerait la main à MathJax-SVG pour les formules les plus complexes serait sûrement le plus léger, mais ça rend naturellement le code côté serveur plus compliqué.

Un système mixte, avec un parseur maison qui passerait la main à MathJax-SVG pour les formules les plus complexes serait sûrement le plus léger, mais ça rend naturellement le code côté serveur plus compliqué.

Sauf que le problème se présente sur des pages chargées en maths, avec des formules "compliquées". Donc il y a deux problèmes, déterminer à l'avance ce qu'est une formule compliquée ou pas est un problème lui-même compliqué, et surtout il y a de fortes chances pour que ça ne change strictement rien du tout (ou très peu) au problème du temps de chargement des pages.