! [spip-dev] Raccourci LaTeX -> MathML

Dev
1

Salut,

Je viens d'uploader un nouveau raccourci qui, sur le modèle de <math>, permet de coder des formules mathématiques en LaTeX. Mais ce coup-ci, le résultat est affiché en MathML.

Vous pouvez voir un exemple à l'adresse:
http://arno.rezo.net/article.php3?id_article=2491
(en début d'article, un lien vers une page qui explique comment installer le nécessaire pour obtenir un affichage de MathML).

Le raccourci s'utilise très largement: <latex>...</latex>, on peut le mettre autour de plusieurs paragraphes.
A l'intérieur, on code les $formules$ avec les dollars simples, ou
$$centrees$$
avec les dollars doubles (comme dans TeX).

Parmi les (énormes) difficultés rencontrées:

- D'abord, il fallait un convertisseur LaTeX -> MathML en php. Il y en a un qui existe: WeM. Je l'ai déjà un peu complété, notamment parce que la plupart des commandes LaTeX doivent être converties dans leur équivalent MathML. Je me suis donc cogné un gros tableau de correspondance...

Là, il y a beaucoup de travail: le convertisseur est très incomplet, y'a pas mal de choses à retravailler dedans...

Volontairement, je ne passe que les formules par le moulinette: le reste de la mise en page (gestion du texte hors équations), ça reste du ressort de SPIP.

- Le second écueil, c'est l'implémentation totalement délirante que Mozilla a fait de MathML: ils ont tout bonnement décidé que ça ne s'affichait qu'en XHTML strict. Pas seulement dans la forme du document, mais il faut aussi absolument balancer en content-type:xml. Déjà c'est la mort de passer en XHTML strict, surtout dans ce mode, Mozilla se met à fonctionner en "débuggueur" de XML (et pas comme un bon vieux client Web)! C'est délirant de chez délirant: ces connards ont codé un brouteur qui se contente d'afficher une ligne d'erreur quand il trouve une erreur XML dans une page Web. Résultat: c'est totalement inutilisable.

Bon, avec MathPlayer pour MSIE, c'est à peine moins chiant...

Du coup, j'ai finalement trouvé un petit script javascript qui rend le MathML "affichable" sur n'importe quelle page Web. (Ce qui montre qu'on a affaire à des blaireaux intégristes...)

- Troisième écueil. Toujours puristes les connards de Mozilla: seuls les glyphes compris dans le format général de la page sont interprétés (c'est tellement logique que c'est en débile). Et en HTML, visiblement, on n'a pas les mêmes glyphes qu'en XML. Donc la plupart des symboles des équations de MathML ne s'affichaient pas dans Mozilla.

Dans inc_charset, je me suis donc codé à la main une translittération du MathML vers unicode. Résultat, tous les caractères "exotiques" de MathML sont désormais balancés sous forme Unicode (hexadecimal). Et devinez quoi, ça provoque quelques caractères fantômes dans MSIE. Et... il y a des caractères unicode visiblement inaccessibles (je ne comprends pas bien pourquoi: ils sont accessibles par leurs glyples!).

2

Vous pouvez voir un exemple à l'adresse:
http://arno.rezo.net/article.php3?id_article=2491

  Impressionant ! Il me dit de télécharger des fontes => y'a des trous
dans le résultat, mais j'en vois 95%, et c'est bô !

Le raccourci s'utilise très largement: <latex>...</latex>, on peut le
mettre autour de plusieurs paragraphes.
A l'intérieur, on code les $formules$ avec les dollars simples, ou
$$centrees$$

  À quoi sert ce raccourci <latex> ? le texte en dehors des $ est
traité comme n'importe quel paragraphe c'est ça ? alors pourquoi ne
pas reprendre <math> plutôt ? quite à utiliser un <MATH> pour le $$

  L'idéal étant d'avoir une option quelque part pour décider si <math>
doir générer des images ou du mathml.

À+, Pif.

3

M'enfin grosso merdo, ça permet déjà de faire des formules de math pas
trop méchantes directement avec SPIP, sans passer par des images. (Au
passage, je ne vois pas trop comment ils espèrent démocratiser mathML avec
des implémentations aussi rigides.)

Il faudra penser à unifier, entre <math>..</math> et <latex>...</latex> ça
va être bordélique :
        1) choisir un raccourci unique (<math>...</math>)
        2) savoir s'il faut ou pas mettre les $ et $$ (dans les deux)
        3) le choix du rendu dépend du site / de la page (ainsi <math> peut
           être rendu par une image sur le site, et par du MathML dans le
           squelette à partir duquel on va générer le PDF

Par ailleurs latex ça m'évoque autre chose que LaTeX... donc bof comme
raccourci, d'autant que c'est quand même TeX qui est le beau programme de
référence, et LaTeX le gros bazar qui se colle par-dessus.

-- Fil

4

Il faudra penser à unifier, entre <math>..</math> et <latex>...</latex> ça
va être bordélique :
        1) choisir un raccourci unique (<math>...</math>)
        2) savoir s'il faut ou pas mettre les $ et $$ (dans les deux)
        3) le choix du rendu dépend du site / de la page (ainsi <math> peut
           être rendu par une image sur le site, et par du MathML dans le
           squelette à partir duquel on va générer le PDF

Cela dit, excellent choix, quel que soit le rendu final, de se baser sur TeX
pour taper les formules.

-- Fil

5

Sous Galeon, certains caractères ne s'affichent pas et l'espacement
entre les symboles est mauvais (de plus une popup javascript vide
s'ouvre au premier chargement de la page). cf. screenshot ci-joint

Sous Konqueror, la plupart des symboles sont remplacés par des carrés
vides.

(l'autre problème avec ta solution est qu'il faut obligatoirement
inclure du javascript)

a+

Antoine.

mathml.png

6

Sous Galeon, certains caractères ne s'affichent pas et l'espacement
entre les symboles est mauvais (de plus une popup javascript vide
s'ouvre au premier chargement de la page). cf. screenshot ci-joint
Sous Konqueror, la plupart des symboles sont remplacés par des carrés
vides.

Oui, je l'ai signalé. Il semble que ça concerne une "tranche" de codes Unicode, de valeur particulièrement élevée. Là, j'ai supposé que quelqu'un de plus expérimenté que moi en Unicode aurait une solution :-))

=> J'ai essayé de passer le résultat par un unicode2charset. Ca n'améliore pas.

(l'autre problème avec ta solution est qu'il faut obligatoirement
inclure du javascript)

Non: le javascript est obligatoire pour que ça s'affiche dans l'espace privé. Sans ça, il est impossible d'afficher du MathML en dehors de xhtml strict (et quand je dis strict, c'est strict: il faut même carrément passer le content-type en une des variantes xml, comme par exemple application/xhtml+xml; auquel cas Mozilla passe en mode débuggage, et là y'a pas vraiment moyen de lui faire afficher grand chose).

En revanche, sur l'espace public, si on construit le site en pur xhtml, à priori, à terme, on peut se passer des bidouilles javascript.

ARNO*

7

Salut,

Je viens d'uploader la modif suivante:

<latex> et <math> fusionnent ainsi:

- le raccourci <latex> disparaît;

- le raccourci <math> fonctionne désormais comme un passage "générique" en mode mathématique, et les formules sont signalées par les raccourcis TeX classiques (dollars et double dollars):

<math>Soit $a > 1$, on a:
$$a+1 > 2.$$</math>
Voir par exemple:
http://arno.rezo.net/article.php3?id_article=2492

=> Selon que l'on fixe une valeur "traiter_maths" (dans le code en dur pour l'instant, c'est dans inc_texte) à "image" ou "mathml", le traitement du même raccourci se fait en mode image ou en mode mathml.

ARNO*

8

Salut,

Il y a deux choses qui seraient vraiment pratiques sur le serveur qui traite les formules TeX:

(1) En passant une option supplémentaire en url, la formule retournée sera du mathML et non une image. De cette façon, le même serveur renverrait, en fonction de la demande, soit une image (actuellement), soit du mathml.

Pour cela, il faudrait installer TeX4ht:
http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html

(2) Améliorer le retour d'image. En particulier: retravailler la ligne de base. Il faut, en sortie de LaTeX, ajouter un traitement pour "agrandir" la boîte traitée, de façon à ce que la ligne de base soit grosso modo au centre vertical de la boîte (en fait, un poil en dessous).

Sinon c'est ultra-moche: les formules apparaissant systématiquement décalées verticalement par rapport au texte autour.

ARNO*

9

Bonjour,

> Il faudra penser à unifier, entre <math>..</math> et <latex>...</latex> ça
> va être bordélique :
> 1) choisir un raccourci unique (<math>...</math>)
> 2) savoir s'il faut ou pas mettre les $ et $$ (dans les deux)
> 3) le choix du rendu dépend du site / de la page (ainsi <math> peut
> être rendu par une image sur le site, et par du MathML dans le
> squelette à partir duquel on va générer le PDF

Cela dit, excellent choix, quel que soit le rendu final, de se baser sur TeX
pour taper les formules.

Pas vraiment.

Bon, reprenons. Si ca a pas trop changé depuis les mails d'annonces (et
j'en ai raté apparemment), et ma discussion avec Benj lors des RMLLs, le
moteur de rendu est sur emma.lautre.net , développé conjointement par
Fil et Benjamin (root de L'Autre Net et mainteneur du logiciel AlternC).

Problème, Georges, mainteneur du paquet debian WIMS, membre de l'Ofset,
et grand habitué des logiciels de math en tant que prof, me conseillait
tantot d'utiliser MathML, plus adapté à la webisation et surtout pour
lequel il existe déjà des méthodes destinées aux non-voyants.

Arno, tu dis dans un de tes mails utiliser une moulinette Latex->MathML
. Mais le rendu png se fait à quel niveau ? Latex->png ou MathML->png ?
Georges est aussi le mainteneur de la moulinette MathML->png . Peut-être
pourriez vous discuter de cela tous ensemble non ? :slight_smile:
Je veux bien faire le relayeur de mails, j'ai pas tout suivi au sujet.

A+

10

DaffyDuke a écrit :

Problème, Georges, mainteneur du paquet debian WIMS, membre de l'Ofset,
et grand habitué des logiciels de math en tant que prof, me conseillait
tantot d'utiliser MathML, plus adapté à la webisation et surtout pour
lequel il existe déjà des méthodes destinées aux non-voyants.

Non, c'est prometteur, mais il n'y a pas encore de solution totalement
utilisable pour le moment. Donc le rendu mathml -> parole n'est pas
encore tout à fait au point, et le mathml est nuisible si on le balance
sur une ligne de braille (trop verbeux), il vaut mieux s'en tenir à TeX,
et surveiller l'avancée des logiciels utilisant mathml.

Georges est aussi le mainteneur de la moulinette MathML->png .

non, je suis mainteneur d'un paquet debian texgd, qui convertit du TeX
en png.

amitiés, Georges.

11

DaffyDuke a écrit :
> Problème, Georges, mainteneur du paquet debian WIMS, membre de l'Ofset,
> et grand habitué des logiciels de math en tant que prof, me conseillait
> tantot d'utiliser MathML, plus adapté à la webisation et surtout pour
> lequel il existe déjà des méthodes destinées aux non-voyants.

Non, c'est prometteur, mais il n'y a pas encore de solution totalement
utilisable pour le moment. Donc le rendu mathml -> parole n'est pas
encore tout à fait au point, et le mathml est nuisible si on le balance
sur une ligne de braille (trop verbeux), il vaut mieux s'en tenir à TeX,
et surveiller l'avancée des logiciels utilisant mathml.

Tu me disais cependant que MathML semblait plus adapté dans le cas d'une
écriture d'un mot "bonjour" pouvant être interprété comme b x o x n x j
x o x u x r au lieu de bonjour.

> Georges est aussi le mainteneur de la moulinette MathML->png .

non, je suis mainteneur d'un paquet debian texgd, qui convertit du TeX
en png.

Ah ben donc il n'a pas l'air dans Woody, à voir si on peut se le
backporter facilement .

12

DaffyDuke a écrit :

> Non, c'est prometteur, mais il n'y a pas encore de solution totalement
> utilisable pour le moment. Donc le rendu mathml -> parole n'est pas
> encore tout à fait au point, et le mathml est nuisible si on le balance
> sur une ligne de braille (trop verbeux), il vaut mieux s'en tenir à TeX,
> et surveiller l'avancée des logiciels utilisant mathml.

Tu me disais cependant que MathML semblait plus adapté dans le cas d'une
écriture d'un mot "bonjour" pouvant être interprété comme b x o x n x j
x o x u x r au lieu de bonjour.

Bonjour Daffy,
j'ai l'impression que tu ne saisis pas le problème. XML c'est très très
bien, tout à fait kasher, mais en général c'est plutôt adapté aux
ordinateurs. Il est préférable de disposer d'une interface utilisateur
consistante avant de présenter ça à des humains.

Comme toi et moi « ne sommes pas des humains », je me propose de montrer
comment se code le produit "b o n j o u r" en mathml, tu recopies les
données suivantes dans un fichier bonjour.xml, et tu verras que Mozilla
sait parfaitement l'interpréter pour un voyant :
--------------------------------8<----------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE math:math PUBLIC "-//OpenOffice.org//DTD Modified W3C MathML 1.01//EN" "math.dtd">
<math:math xmlns:math="http://www.w3.org/1998/Math/MathML&quot;&gt;
  <math:semantics>
    <math:mrow>
      <math:mrow>
  <math:mrow>
    <math:mrow>
      <math:mrow>
        <math:mrow>
    <math:mi>
      b
    </math:mi>
    <math:mo math:stretchy="false">
      <mchar name="InvisibleTimes"/>
    </math:mo>
    <math:mi>
      o
    </math:mi>
        </math:mrow>
        <math:mo math:stretchy="false">
    <mchar name="InvisibleTimes"/>
        </math:mo>
        <math:mi>
    n
        </math:mi>
      </math:mrow>
      <math:mo math:stretchy="false">
        <mchar name="InvisibleTimes"/>
      </math:mo>
      <math:mi>
        j
      </math:mi>
    </math:mrow>
    <math:mo math:stretchy="false">
      <mchar name="InvisibleTimes"/>
    </math:mo>
    <math:mi>
      o
    </math:mi>
  </math:mrow>
  <math:mo math:stretchy="false">
    <mchar name="InvisibleTimes"/>
  </math:mo>
  <math:mi>
    u
  </math:mi>
      </math:mrow>
      <math:mo math:stretchy="false">
  <mchar name="InvisibleTimes"/>
      </math:mo>
      <math:mi>
  r
      </math:mi>
    </math:mrow>
  </math:semantics>
</math:math>
--------------------------------8<----------------------------

Maintenant ferme les yeux un instant et mets-toi à la place d'un
aveugle, qui explore la même expression sous lynx, avec sa ligne de
braille 80 caractères. Certes c'est de l'ascii. Mais il en a pour dix
bonnes minutes avant de remarquer le sens de ce qu'il peut lire.
Quand nous disposerons d'un bon rendu vocal pour Mathml, ce sera
différent : une feuille de style et hop là boum c'est bon. Au jour
d'aujourd'hui il est urgent de travailler à obtenir ce rendu vocal, et
garder à la tête que Mathml permet d'exprimer plus que LaTeX.
Comprends-tu ce que je voulais dire quand j'écrivais que Mathml est
verbeux ?

> > Georges est aussi le mainteneur de la moulinette MathML->png .
>
> non, je suis mainteneur d'un paquet debian texgd, qui convertit du TeX
> en png.

Ah ben donc il n'a pas l'air dans Woody, à voir si on peut se le
backporter facilement .

Tu trouves un paquet Sarge de texgd, avec les lignes suivantes dans
sources.list :
deb ftp://developer.ofset.org sarge main
deb-src ftp://developer.ofset.org sarge main

texgd est un des composants de Wims dont l'auteur est Gang Xiao, je l'ai
isolé dans un paquet car il fournit une fonctionnalité plutôt
transversale. Il doit se compiler facilement aussi pour woody.

amitiés, Georges.

13

Bon, reprenons. Si ca a pas trop changé depuis les mails d'annonces (et
j'en ai raté apparemment), et ma discussion avec Benj lors des RMLLs, le
moteur de rendu est sur emma.lautre.net , développé conjointement par
Fil et Benjamin (root de L'Autre Net et mainteneur du logiciel AlternC).

Euh, oui, enfin : le serveur est basé sur tex2im, avec un wrapper php qui
fait office de cache, et une instance de ce serveur est sur emma.lautre.net,
mais j'espère qu'on pourra en avoir plusieurs

Problème, Georges, mainteneur du paquet debian WIMS, membre de l'Ofset,
et grand habitué des logiciels de math en tant que prof, me conseillait
tantot d'utiliser MathML, plus adapté à la webisation et surtout pour
lequel il existe déjà des méthodes destinées aux non-voyants.

Les nouvelles méthodes introduites par Arno permettent de choisir entre les
deux rendus : TeX et MathML. Mais le code de base est du TeX.

Arno, tu dis dans un de tes mails utiliser une moulinette Latex->MathML
. Mais le rendu png se fait à quel niveau ? Latex->png ou MathML->png ?

C'est TeX -> PNG ou TeX -> MathML.

> non, je suis mainteneur d'un paquet debian texgd, qui convertit du TeX
> en png.

Ca doit faire double emploi avec tex2im, mais si c'est meilleur pas de
problème pour changer de fusil d'épaule : le seul truc est l'interface du
serveur, très simple : cf. http://wiki.rezo.net/test/TeX

-- Fil

14

Fil a écrit :

Euh, oui, enfin : le serveur est basé sur tex2im, avec un wrapper php qui

C'est à http://www.nought.de/tex2im.php ?

Ça semble intéressant.
C'est un script en shell qui enrobe LaTeX, dvips et convert.

texgd est écrit en C, il faut pour l'appeler initialiser une poignée de
variables d'environnement, et il court-circuite dvips et convert en
interprétant directement le fichier temporaire dvi à l'aide de la
bibliothèque gd. L'appel de TeX par contre n'est pas court-circuité.

amitiés, Georges.

15

> Euh, oui, enfin : le serveur est basé sur tex2im, avec un wrapper php qui

C'est à http://www.nought.de/tex2im.php ?

Oui.

Ça semble intéressant.
C'est un script en shell qui enrobe LaTeX, dvips et convert.

texgd est écrit en C, il faut pour l'appeler initialiser une poignée de
variables d'environnement, et il court-circuite dvips et convert en
interprétant directement le fichier temporaire dvi à l'aide de la
bibliothèque gd. L'appel de TeX par contre n'est pas court-circuité.

Ca signifie que c'est plus performant ? En tout cas c'est un plaisir que tu
sois sur cette liste, ça pourra nous aider :slight_smile:

Pour monter un autre serveur de TeX tu peux te baser sur le code du serveur,
qui se trouve à l'adresse: http://wiki.rezo.net/test/TeX vers le bas de la
page.

Les modifs récentes faites par Arno* dans le code SPIP suggèrent qu'on peut
améliorer le serveur en ajoutant le code ci-dessous autour de la formule
passée en argument. Par ailleurs la géométrie 90x90 passée à tex2im n'est
pas forcément optimale.

La modif d'Arno* :

        $tex = "\large\\setbox1=\\hbox{\$\\displaystyle ".$tex."\$}\n"
                ."\\newdimen\\haut\n\\newdimen\prof\n"
                ."\\haut=\\ht1\n\\prof=\\dp1\n"
                ."\\ifdim\\haut>\\prof\\prof=\\haut\\else\\haut=\\prof\\fi\n"
                ."\\advance\haut by .5em\n"
                ."\\color{white}\\vrule height \\haut depth \\prof width 0.1pt\\color{black}\\box1";

perso je pense que le \large est de trop.

-- Fil

16

Fil a écrit :

> texgd est écrit en C, ...

Ca signifie que c'est plus performant ?

À mon avis oui. Fais quelques tests si tu veux. Si ça ne marche pas du
premier coup je peux te donner une recette qui fonctionne.

Les modifs récentes faites par Arno* dans le code SPIP suggèrent qu'on peut
améliorer le serveur en ajoutant le code ci-dessous autour de la formule
passée en argument. Par ailleurs la géométrie 90x90 passée à tex2im n'est
pas forcément optimale.

Je ne suis pas spécialiste de TeX, juste un empaqueteur de certaines
choses qui me dépassent.

amitiés, Georges.

17

> texgd est écrit en C, il faut pour l'appeler initialiser une poignée de
> variables d'environnement, et il court-circuite dvips et convert en
> interprétant directement le fichier temporaire dvi à l'aide de la
> bibliothèque gd. L'appel de TeX par contre n'est pas court-circuité.

Ca signifie que c'est plus performant ? En tout cas c'est un plaisir que tu
sois sur cette liste, ça pourra nous aider

Je viens de faire un essai avec texgd; voir :

http://wiki.rezo.net/test/TeXGD

Il y a un bug de mise en page (le numéro 1 qui se balade en bas, rien de
grave)... mais je trouve que l'image est moins belle - faut-il ajouter des
réglages particuliers ?