[spip-dev] TeX

Dev
1

Coucou,

j'envoie sur wiki.rezo.net/test/TeX une nouvelle version du serveur de TeX
et le code client qui va avec dans le CVS... la "ligne de base" et
l'agrandissement sont désormais traités au niveau du serveur, et pas du
client.

* pour la transparence : tex2im a bien une option (-z) pour faire des png
  transparents, mais le résultat "bave" horriblement

* pour les réponses dans le forum interne, c'étaient de vieux stripslashes()
  qui trainaient

Maintenant il faudrait vraiment se décider pour une syntaxe légère : soit
<math>...</math> comme avant, soit $x$ etc., mais alors il faut trouver les
regexp qui conviennent. Le mélange des deux donne un truc embrouillé qui ne
me convient pas.

-- Fil

2

Maintenant il faudrait vraiment se décider pour une syntaxe légère : soit
<math>...</math> comme avant, soit $x$ etc., mais alors il faut trouver les
regexp qui conviennent. Le mélange des deux donne un truc embrouillé qui ne
me convient pas.

Ce matin ça me convient mieux :
" Afin de conserver un fonctionnement normal aux sites voulant afficher des
$ ces raccourcis ne sont disponibles que si vous mettez <math> quelque part
avant dans le texte ; il est aussi possible de mettre </math> pour refermer
le mode math et afficher des $ norrmalement, comme ici."

La seule modif que je veux faire, donc, c'est de ne pas obliger
l'utilisateur à refermer son texte par </math>. S'il met <math> en début de
texte, alors c'est bon.

Restera à régler le cas mathML. Pour l'instant je dirais que ça n'est pas
vraiment prêt :slight_smile:

-- Fil

3

C'est compliqué. Je trouve qu'il serait plus simple de garder le <math>
(avec obligation de fermer la balise pour ne pas encourager les
mauvaises pratiques qui seront balayées par le spip-validator dans
quelques années ;)), c'est une notation assez explicite et qui évite les
surprises bizarres si un $texte$ se trouve dans un article existant.

a+

Antoine.

4

C'est compliqué. Je trouve qu'il serait plus simple de garder le <math>
(avec obligation de fermer la balise pour ne pas encourager les
mauvaises pratiques qui seront balayées par le spip-validator dans
quelques années ;)), c'est une notation assez explicite et qui évite les
surprises bizarres si un $texte$ se trouve dans un article existant.

L'idéal serait de trouver la regexp qui va bien et qui prend $ et $$
seulement quand c'est nécessaire. Et pour les quelques cas où la regexp
pense que c'est de la monnaie US et pas de la formule de math, utiliser
<math></math>, pour lever l'ambiguité.

Car en effet, si je suis matheux, et que je tape mon site en pseudo-tex, je
n'ai pas tellement envie de devoir taper <math>x</math> là où dans ma thèse
je tape $x$. Sinon les copiés-collés vont être un peu pénibles.

-- Fil

5

L'idéal serait de trouver la regexp qui va bien et qui prend $ et $$
seulement quand c'est nécessaire.

C'est clair. Si dans un article je dis "les variables $mysql_debug et
$mysql_profile permettent d'afficher des informations relatives aux
requêtes exécutées par le système", il ne faut pas que "$mysql_debug et
$" soit considéré comme une formule de maths.

Ou alors utiliser un caractère beaucoup plus rare, comme µ (µ = m =
maths ;-)). Mais je ne sais pas pas s'il est accessible sur tous les
claviers.

Car en effet, si je suis matheux, et que je tape mon site en pseudo-tex, je
n'ai pas tellement envie de devoir taper <math>x</math> là où dans ma thèse
je tape $x$. Sinon les copiés-collés vont être un peu pénibles.

On rentre dans des tas d'utilisations spécifiques. Un programmeur qui
écrit la doc interne d'un logiciel voudra citer des bouts de code PHP
sans réécrire <cadre> </cadre> à chaque fois, il aimerait donc détecter
<?php et ?> pour mettre un cadre autour. etc.

Ce genre de bidules "magiques" seraient mieux traités en amont par un
système d'importation, ou bien un filtre spécifique au site.
(#TEXTE|latex) par exemple... avec l'inconvénient que cela ne s'affiche
pas correctement dans l'espace privé - ou bien positionner une variable
ad hoc dans mes_options.

a+

Antoine.

6

- La situation actuelle ne me semble tout de même pas bien méchante: placer des $...$ et $$...$$ à l'intérieur d'un <math></math> ne m'apparaît pas si lourd. Déjà les habitués de LaTeX utilisent de lourds:
\begin{document}...\end{document}

- De plus, on peut imaginer étendre dans le mode <math></math> quelques autres méthodes de Latex, incompatibles jusque là avec SPIP. Ce qu'un simple jeu sur les $...$ et $$...$$ laisserait toujours bancal.

      * Parser dans ce mode les \$ comme symbole de la monnaie dollar (pour ceux qui ont tout de même besoin d'afficher une somme en dollars à l'intérieur d'un texte comportant des maths).

      * Éventuellement ajouter quelques autres méthodes LaTeX, comme: \[...\] (équivalent de $$...$$).

      * Si le but est de faciliter les copier-coller depuis des documents LaTeX (sans non plus faire un parser complet), parser des trucs très usuels, tels que \textbf, \textsl...*

      * Balancer, à l'ouverture du mode mathématique, un <span class="spip_math">, ce qui permettrait d'affiner localement l'affichage du texte qui accompagne les maths, ou je ne sais quelle subtilité. Par exemple, fixer localement la taille, la police et la couleur des caractères du texte (le site pouvant, par ailleurs, avoir un affichage très différent), pour être certain, à ces endroits-là, d'avoir un affichage cohérent entre le texte et les formules de math...

      * Par la suite, d'autres trucs possibles... A condition, toujours, d'avoir une ouverture et fermeture définissant ainsi un "mode mathématique".

7

- De plus, on peut imaginer étendre dans le mode <math></math> quelques
autres méthodes de Latex, incompatibles jusque là avec SPIP. Ce qu'un
simple jeu sur les $...$ et $$...$$ laisserait toujours bancal.

     * Parser dans ce mode les \$ comme symbole de la monnaie dollar (pour
ceux qui ont tout de même besoin d'afficher une somme en dollars à
l'intérieur d'un texte comportant des maths).

Oui, mais attention aux \$ à l'intérieur des $...$ :slight_smile:

     * Éventuellement ajouter quelques autres méthodes LaTeX, comme:
\[...\] (équivalent de $$...$$).
     * Si le but est de faciliter les copier-coller depuis des documents
LaTeX (sans non plus faire un parser complet), parser des trucs très
usuels, tels que \textbf, \textsl...*

Là ça me paraît too much.

     * Balancer, à l'ouverture du mode mathématique, un <span
class="spip_math">, ce qui permettrait d'affiner localement l'affichage du
texte qui accompagne les maths, ou je ne sais quelle subtilité. Par
exemple, fixer localement la taille, la police et la couleur des
caractères du texte (le site pouvant, par ailleurs, avoir un affichage
très différent), pour être certain, à ces endroits-là, d'avoir un
affichage cohérent entre le texte et les formules de math...

Oui !

- Je tiens à ce qu'on puisse choisir l'affichage MathML en option (via
variable dans $mes_fonctions). L'installation des extensions MathML, sous
Windows, avec les polices qui vont bien, c'est pas la mer à boire. Un
premier CMS grand public permettant de produire du MathML, ça peut
contribuer à motiver un peu plus les développeurs (de brouteurs, comme de
convertisseurs).

OK, mais ne soumets pas tout le fonctionnement de spip à cette exigence. Si
l'usage de MathML implique l'obligation d'avoir tidy(), c'est pas si grave,
puisque php5 arrive.

-- Fil

8

'intérieur d'un texte comportant des maths).

     * Balancer, à l'ouverture du mode mathématique, un <span
class="spip_math">, ce qui permettrait d'affiner localement l'affichage du
texte qui accompagne les maths, ou je ne sais quelle subtilité. Par
exemple, fixer localement la taille, la police et la couleur des
caractères du texte (le site pouvant, par ailleurs, avoir un affichage
très différent), pour être certain, à ces endroits-là, d'avoir un
affichage cohérent entre le texte et les formules de math...

Oui !

Euh, en fait je me suis avancé: avec un span on est encore partis pour produire du code pas compliant, dès lors que les maths concernent plusieurs paragraphes.

Faut en discuter. Le plus simple consisterait à décider que le passage en mode mathmétique ouvre un <div>, et ça on sait mieux gérer (voir l'évolution des <quote> récente).

OK, mais ne soumets pas tout le fonctionnement de spip à cette exigence.

Bien d'accord. Il suffit que je désactive le javascript MathML et l'appel de l'extension pour MSIE dans l'espace privé, et ne les activer qu'en présence de la variable dans spip_options.

Si
l'usage de MathML implique l'obligation d'avoir tidy(), c'est pas si grave,
puisque php5 arrive.

Non, MathML n'implique pas d'avoir tidy, puisque j'ai réussi à activer MathML même en dehors d'un XHTML ultra-valide (notamment l'espace privé).

Le seul lien entre MathML et Tidy, c'est que si on passe le site public en XHTML qui va bien (donc via Tidy), et avec le header application/xml (pour Mozilla), alors le MathML est interprété sans autre modification.

Mais même là, si on veut un site avec du HTML normal (et même pas forcément pas bien valide), le recours au javascript tel qu'utilisé dans l'espace privé permet de récupérer l'affichage MathML. Suffira de faire une page de documentation l'expliquant. C'est pas très méchant.

Les deux choses qui posent réellement problème quant à MathML:

- l'absence d'installation automatique de toutes les polices mathématiques d'un seul coup; c'est, côté brouteurs, la principale limitation. C'est vraiment très con, parce que des polices mathématiques libres, autour de TeX, y'en a des tripotées, suffirait que quelqu'un s'y mette une bonne fois pour toute pour en faire une, bien GPL et tout... donc que ça soit installé avec Mozilla (déjà ça aiderait);

- de notre côté: la moulinette LaTeX vers MathML. Celle qu'on utilise produit déjà des résultats intéressants, mais est incomplète, et beaucoup de choses importantes manquent.

C'est sur ce point qu'on peut espérer que l'intégration dans SPIP pourra motiver des développeurs. Parce qu'on fournit une énorme facilité d'utiliser et d'intégrer les résultats de ce moteur (ce qui n'existait pas auparavant avec des outils réellement faciles à utiliser). Avec un tel outil, ça donne une bonne raison aux matheux et aux informaticiens pour améliorer rapidement ce moteur.

ARNO*