[spip-dev] Re: spip et mathml

Oui, c'est même prévu d'intégrer ça dans SPIP en standard, et très
bientôt !

C'est plutôt du dev, alors je passe sur cette liste.

Si vous intégrez Tex en standard dans spip, je me disais que ça serait
presque sympa de faire un système générique: la fonctions de cache de
l'image générée et du serveur/commande externe reste identique, mais
on peut configurer quoi utiliser comme on ajouterait un filtre typo
dans mes_options. De cette façon, la mise en place d'autre générateur
d'image externe (gnuplot, graphviz, etc...) serait aisé dans spip, en
fonction du but du site.

Pour le moment, la balise <math> permet d'intercepter des commandes
latex. On pourrait imagine une balise <generer_image(latex)> qui
prend un type de contenue en paramètre.

Dans le fichier mes_options, on aurait un tableau de mapping:

$generateur_image = ('latex' => 'math_image',
'gnuplot' => 'plot_image',
'graphviz' => 'dot_image'
);

qui pointe, pour un type de générateur vers un nom de
fonction. Chacune de ces fonctions est aussi définie dans mes_options
et est appelé là:

$func_gen = $generateur_image[$nom_gen];

// (Re)Creer l'image, en local ou en client-serveur
if (!file_exists($fichier)) {
$fichier = $func_gen($texte);
}

on pourrait imaginer un truc encore plus générique, où l'on a juste à
mapper un nom de générateur sur une commande shell, mais je pense que
ça ne serait pas assez souple.

Si ça vous intéresse, je code un vraie truc à partir du code donné sur
le wiki.

Pierre

Si vous intégrez Tex en standard dans spip, je me disais que ça serait
presque sympa de faire un système générique: la fonctions de cache de
l'image générée et du serveur/commande externe reste identique, mais
on peut configurer quoi utiliser comme on ajouterait un filtre typo
dans mes_options. De cette façon, la mise en place d'autre générateur
d'image externe (gnuplot, graphviz, etc...) serait aisé dans spip, en
fonction du but du site.

Comme tu as vu, le code du "client TeX" est très court ; pas la peine donc,
à mon avis, de monter un truc "générique" avant que le besoin ne se
présente vraiment. A la limite on mettra le code client/serveur dans une
fonctione spécialisée.

Par contre c'est vrai que les regexp qui sont utilisées dans echappe_html()
sont un poil complexes : dès qu'on arrivera à se décider à imposer la
librarie preg* ça va se simplifier à mort :slight_smile:

-- Fil