Désactiver les commandes de mise en forme ?

Bonjour,

Nous sommes en train de mettre en place un portail en SPIP pour "Images
des Mathématiques", et j'ai une question technique.

Il y a un logiciel génial qui s'appelle jsMath, et qui permet d'utiliser
la syntaxe TeX dans une page web, le script (en javascript) s'occupant
de la mise en forme. Il utilise effectivement une vertion TTF de la
police Computer Modern, c'est assez spectaculaire à voir.

Bref, le code HTML ressemble à ça :

<div class="math">
  \sum_{i=1}^{+\infty} \frac{1}{i^2} = \frac {\pi^2}{6}
</div>

ou bien, en version raccourcie, à ça :

$$\sum_{i=1}^{+\infty} \frac{1}{i^2} = \frac {\pi^2}{6}$$

Maintenant on voudrait profiter de ça dans SPIP, et il y a un problème,
qui est que SPIP remplace les accolades par <i>...</i>, et alors jsMath
y perd son latin.

Comment faire pour désactiver ça à l'intérieur de paires de dollars / de
doubles dollars, ou à l'intérieur de balises spip spéciales genre
<jsmath></jsmath> ? [Je vais éviter <math></math> qui existe déjà.]

Merci d'avance, et bravo pour ce logiciel génial !

  /vincent

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25

Bonjour,

Les éléments que tu cites sont ajoutés dans le champ TEXTE d’un article je suppose?
SI c’est oui, il faudrait que dans ton champ texte tu entoures tes codes LaTex par (désactive le traitement typographique automatique de SPIP) ou

Le 11/02/08, Vincent Beffara <vbeffara+ml@gmail.com> a écrit :

Bonjour,

Nous sommes en train de mettre en place un portail en SPIP pour « Images
des Mathématiques », et j’ai une question technique.

Il y a un logiciel génial qui s’appelle jsMath, et qui permet d’utiliser
la syntaxe TeX dans une page web, le script (en javascript) s’occupant
de la mise en forme. Il utilise effectivement une vertion TTF de la
police Computer Modern, c’est assez spectaculaire à voir.

Bref, le code HTML ressemble à ça :

\sum_{i=1}^{+\infty} \frac{1}{i^2} = \frac {\pi^2}{6}

ou bien, en version raccourcie, à ça :

$$\sum_{i=1}^{+\infty} \frac{1}{i^2} = \frac {\pi^2}{6}$$

Maintenant on voudrait profiter de ça dans SPIP, et il y a un problème,
qui est que SPIP remplace les accolades par , et alors jsMath
y perd son latin.

Comment faire pour désactiver ça à l’intérieur de paires de dollars / de
doubles dollars, ou à l’intérieur de balises spip spéciales genre
? [Je vais éviter qui existe déjà.]

Merci d’avance, et bravo pour ce logiciel génial !

/vincent


Vincent Beffara
UMPA - ENS-Lyon
46 allée d’Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25


liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip.net/fr_article1054.html

Bonjour,

Les éléments que tu cites sont ajoutés dans le champ TEXTE d'un article je
suppose?
SI c'est oui, il faudrait que dans ton champ texte tu entoures tes codes
LaTex par <html></html> (désactive le traitement typographique automatique
de SPIP) ou <code></code>...

Certes, on peut faire comme ça (et c'est en effet dans le champ TEXTE).
Mais je voudrais que ce soit le plus simple possible pour les
utilisateurs, et si possible autoriser un contenu du genre

{{{Fonctions continues sur $\mathbb R$}}}

On peut dire

{{{Fonctions continues sue <html>$\mathbb R$</html>}}}

mais c'est un peu lourd. Ce que je me disais c'est qu'il y a déjà une
balise <math> qui attrappe son contenu avant l'interprétation des
{}, et qui en fait un truc sioux. Il y a moyen de traiter le champ TEXTE
au moment de la composition pour insérer les paires <html></html>
automatiquement avant que SPIP ait le temps de faire son traitement
typographique ? En reprenant essentiellement ce que fait <math></math>
par défaut, ça doit être jouable, non ?

Je pensais mettre dans mon squelette du code qui ressemblerait par exemple à

[(#TEXTE|protect_math_from_typography)]

et avoir une fonction PHP qui fait ce que je veux, mais avant d'y perdre
un week-end je voudrais être sûr que je vais dans la bonne direction ...

Bien sûr si c'est invisible aussi dans le squelette, c'est mieux !

[Je ne suis pas contre mettre les mains dans le cambouis et faire du
PHP, mais mon but c'est que ce soit transparent pour l'utilisateur
final, donc si on passe par <html></html> il faut qu'il soit inséré
automatiquement ...]

  /vincent

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25

Je pensais mettre dans mon squelette du code qui ressemblerait par exemple à

[(#TEXTE|protect_math_from_typography)]

et avoir une fonction PHP qui fait ce que je veux, mais avant d'y perdre
un week-end je voudrais être sûr que je vais dans la bonne direction ...

... bon ben voila. Merci pour m'avoir indiqué le coup du <html></html>,
tu m'as donné l'inspiration qu'il me fallait, et je me réponds moi-même
parce que ça peut toujours servir à d'autres. Voila un principe qui a
l'air de marcher : ce qu'on veut faire c'est intercaler un filtre avant
la fonction propre(), du coup

- dans mes_fonctions.php,

function protect_math ($texte) {
  // Bon, là je ne l'ai pas encore fait, mais à base de ereg_replace on
  // ajoute des paires de balises <html></html> bien placées, en
  // recopiant plus ou moins le code de ecrire/inc/math.php. J'ai fait
  // le test débile en remplaçant les '$' par des 'S' et ça fait ce que
  // je veux. Après il faut réfléchir un peu, mais ce n'est pas la
  // partie qui m'inquiète.

  return $texte;
}

- dans le squelette qu'on veut,

[(#TEXTE*|protect_math|propre)]

M'enfin il me reste deux questions :

* Est-ce que ce que je fais est dangereux ? (Du genre à mal interagir
  avec certains plugins, par exemple ...)

* Est-ce qu'il y a un moyen de dire à SPIP "tu intercaleras cette
  fonction à chaque fois que tu appelleras propre() sans que je te le
  dise" ?

La deuxième est un peu mineure, c'est surtout pour ma culture
personnelle en fait, mais je me dis que mettre des maths dans un
descriptif, ou dans un post-scriptum, ou dans un titre, ou enfin bref
ailleurs que dans un #TEXTE ça peut être utile, et à tous les coups je
vais me vautrer et oublier un filtre quelque part ...

Merci encore pour votre aide,

  /v

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25

On 2008-02-11 21:08:06 +0100, Vincent Beffara <vbeffara+ml@gmail.com> said:

Je pensais mettre dans mon squelette du code qui ressemblerait par exempl

e à

[(#TEXTE|protect_math_from_typography)]

et avoir une fonction PHP qui fait ce que je veux, mais avant d'y perdre

un week-end je voudrais être sûr que je vais dans la bonne direction

...

... bon ben voila. Merci pour m'avoir indiqué le coup du <html></html>,

tu m'as donné l'inspiration qu'il me fallait, et je me réponds moi-mê
me

parce que ça peut toujours servir à d'autres. Voila un principe qui a

l'air de marcher : ce qu'on veut faire c'est intercaler un filtre avant

la fonction propre(), du coup

- dans mes_fonctions.php,

function protect_math ($texte) {
  // Bon, là je ne l'ai pas encore fait, mais à base de ereg_replace on

  // ajoute des paires de balises <html></html> bien placées, en

  // recopiant plus ou moins le code de ecrire/inc/math.php. J'ai fait

  // le test débile en remplaçant les '$' par des 'S' et ça fait ce q
ue

  // je veux. Après il faut réfléchir un peu, mais ce n'est pas la

  // partie qui m'inquiète.

  return $texte;
}

Bon, ceci m'a motivé moi aussi à essayer de faire marcher jsMath avec spip (j'avais renoncé il y a quelques mois faute de temps) sachant que mon site fonctionne actuellement avec un vilain mélange de mimetex et de tex2png...

jsMath donne souvent un meilleur rendu en termes d'alignements, et le redimensionnement à la volée des formules mathématiques est très agréable...

- dans le squelette qu'on veut,

[(#TEXTE*|protect_math|propre)]

M'enfin il me reste deux questions :

* Est-ce que ce que je fais est dangereux ? (Du genre à mal interagir

  avec certains plugins, par exemple ...)

Ca l'est moins que ce que j'aurais tendance à faire, par paresse (directement éditer math.php, plutôt que de rajouter une surcouche...)

En revanche, s'il s'agit de placer des balises <html> et </html>, elles ne passent pas très bien sous firefox, les espaces se trouvent tronqués après un </html> (pas de problème sous safari et IE7 il me semble), ainsi les formules mathématiques en ligne donnent un affichage fort disgracieux dans ce cas...

Bref, il faut se débrouiller pour que un $x+y$ se trouve transformé en du
<span class="math">x+y</span> plutôt qu'en du
<html><span class="math">x+y</span></html> ce qui complique un peu les corrections à effectuer...

Je serais tenté de patcher inc/texte.php pour que soient supprimées les balises <html> et </html> (y a-t-il des cas où elles servent vraiment à quelque chose ?)

Voyez-vous une meilleure méthode ?

Pierre-Henri Jondot

Bonjour,

En remplaçant le code $formule$ par <span class="math">formule</span>
et $$formule$$ par <p><div class="math">formule</span></p> (sans introduire de balises <html> et </html>) il semble que les commandes de mise en forme ne viennent pas perturber le texte entre ces balises (en tout cas sur mon site testé en local).

En revanche, les formules n'apparaissent pas dans la partie privée du site, et pour cause, le script (javascript) qui s'en charge n'est pas chargé (il l'est dans la partie publique en rajoutant ce qu'il faut dans les squelettes...)

Bref, pour rajouter un truc du genre
<SCRIPT SRC="../jsMath/easy/load.js"></SCRIPT>
pour que les formules s'affichent correctement dans la partie privée du site, comment (et surtout où) faire ?

Pierre-Henri Jondot

Bonjour,

Bonjour,

En remplaçant le code $formule$ par <span class="math">formule</span>
et $$formule$$ par <p><div class="math">formule</span></p> (sans
introduire de balises <html> et </html>) il semble que les commandes de
mise en forme ne viennent pas perturber le texte entre ces balises (en
tout cas sur mon site testé en local).

J'ai en effet constaté cette disparition des espaces après les formules,
sans pouvoir l'expliquer ... mais quand je fais comme tu suggères, SPIP
continue à transformer les accolades en italiques. Une solution serait
de faire un truc du genre

<span class="math><html>u_{n+1}</html></span>

en espérant que l'espace après </span> reste. Mon code pour l'instant
est le suivant :

function vb_filtre ($texte) {
  $texte = preg_replace ('/\$\$([^$]+)\$\$/s', '\\[\1\\]', $texte);
  $texte = preg_replace ('/\$([^$]+)\$/s', '\\(\1\\)', $texte);

  $texte = preg_replace ('/\\\\\\(/', '<html>$', $texte);
  $texte = preg_replace ('/\\\\\\)/', '$</html>', $texte);
  $texte = preg_replace ('/\\\\\\[/', '<html>$$', $texte);
  $texte = preg_replace ('/\\\\\\]/', '$$</html>', $texte);

  while (preg_match ('/<html>[$]+[^$]+</s', $texte)) {
    $texte = preg_replace ('/(<html>[$]+[^$]+)</s', '\1&lt;', $texte);
  }

  $texte = clean_TeX($texte);
  return $texte;
}

(clean_TeX fait des trucs du genre \'e -> &eacute etc.) Ça marche à peu près
bien, cf. le site en travaux ici : http://images.math.cnrs.fr/ (sous-repertoire
spip/ de la racine du site - merci de ne pas rendre ce lien public tant qu'il
est en travaux ...) On y perd la possibilité de mettre des '$' dans le texte,
si on veut la conserver il suffit de supprimer les deux premières lignes
et de se limiter à la notation \(x+y\).

Dernière chose, j'ai activé tex2math dans jsMath - pour que le code
source de la page ressemble à du TeX, ce qui est agréable pour la
lecture en mode texte / sans javascript. Mais vu qu'on fait un
traitement automatique, c'est facile de passer à <span>/<div> à la fin.
Juste la traduction de < en &lt; devient un peu pénible.

Reste le coup de la mise automatique en pipeline. En mettant le filtre
dans pre_propre OU dans pre_typo, il manque des champs ; en le mettant
dans les deux, il est appliqué deux fois, et ça m'a posé des problèmes
...

À la réflexion (et à la lecture du code de SPIP, où on se noie
facilement) le mieux serait de transformer $x+y$ en <span
class="base64_encoded">29872937492847982734982738</span> où enfin je ne
sais plus exactement mais enfin ce que fait <html>. Du coup ça ne
s'applique qu'une fois, ça protège les maths de toute la suite, ça me
semble un bon compromis.

Reste à implémenter !

À suivre, donc.

  /v

En revanche, les formules n'apparaissent pas dans la partie privée du
site, et pour cause, le script (javascript) qui s'en charge n'est pas
chargé (il l'est dans la partie publique en rajoutant ce qu'il faut
dans les squelettes...)

Pas trop grave, tant que les formules apparaissent en prévisualisation
on peut faire avec ...

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25

En remplaçant le code $formule$ par <span class="math">formule</span>
et $$formule$$ par <p><div class="math">formule</span></p> (sans
introduire de balises <html> et </html>) il semble que les commandes de
mise en forme ne viennent pas perturber le texte entre ces balises (en
tout cas sur mon site testé en local).

J'ai en effet constaté cette disparition des espaces après les formules,
sans pouvoir l'expliquer ... mais quand je fais comme tu suggères, SPIP
continue à transformer les accolades en italiques.

C'est donc qu'on n'a pas le même spip... (le mien est en 1.9.2b ou un truc
comme cela)

Je suis en 1.9.2d - mais bon là je parle un peu de mémoire, il faudra
que ja fasse une liste de tous les cas pour la garder quelque part.

Je me demande (au pif, je ne connais rien au php...) si ce code, présent
dans inc/texte.php est ce qui protège les <span> et <div> :

------------------
//
// Echapper les les elements perilleux en les passant en base64
//

// Creer un bloc base64 correspondant a $rempl ; au besoin en marquant
// une $source differente ; le script detecte automagiquement si ce qu'on
// echappe est un div ou un span
// http://doc.spip.org/@code_echappement
function code_echappement($rempl, $source='') {
  if (!strlen($rempl)) return '';

  // Convertir en base64
  $base64 = base64_encode($rempl);

  // Tester si on echappe en span ou en div
  $mode = preg_match(',</?('._BALISES_BLOCS.')[>[:space:]],iS', $rempl) ?
    'div' : 'span';
  $nn = ($mode == 'div') ? "\n\n" : '';

  return
    inserer_attribut("<$mode class=\"base64$source\">", 'title', $base64)
    ."</$mode>$nn";
}
------------------

Oui, si je comprends bien ce qui se passe, avant d'appliquer la typo
SPIP transforme <html> en un span ou un div "opaque" encodé en base64,
puis fait sa typo et tout, et ensuite décode les blocs en question (et
où la typo n'a pas été faite parce que le contenu était caché) avamt
l'affichage final. C'est assez malin comme méthode, et je pense que
c'est adaptable pour jsMath - on peut même sans soute appeler cette
fonction directement.

J'ai posté les modifications sur mon site : http://www.mpkju.fr
pas de problème pour l'échappement des {} semble-t-il. (Voir la banque
d'exercices pour quelques exemples...)

Reste bloqué à l'affichage "loading jsMath" sauf pour les pages de
rubriques ... donc on voit du code TeX. (J'utilise Opera sous Solaris,
je sais que je cherche les ennuis, mais c'est pas entièrement ma faute.)

En revanche, j'ai un curieux bug avec les navigateurs internet explorer,
avec jsMath qui se plaint en prétendant avoir été chargé depuis un autre
domaine, alors qu'il est obtenu avec un lien relatif... Peut-être qu'un
lien en dur marche mieux, je testerai plus tard.

Ton lien dit <SCRIPT SRC="../jsMath/easy/load.js"></SCRIPT> dans la page
http://www.mpkju.fr/spip.php?article137, le '..' est de trop ! Je dirais
src="/jsMath/easy/load.js".

Dernière chose, j'ai activé tex2math dans jsMath - pour que le code
source de la page ressemble à du TeX, ce qui est agréable pour la
lecture en mode texte / sans javascript. Mais vu qu'on fait un
traitement automatique, c'est facile de passer à <span>/<div> à la fin.
Juste la traduction de < en &lt; devient un peu pénible.

Elle n'est pas forcément nécessaire, pourvu de suivre les < et > d'espaces,
ce qui n'est pas une si grande contrainte je trouve.

Ah, ce serait vrai si c'était moi qui écrivais les articles, mais les
matheux ne sont pas des gens disciplinés. Comme les gens qui vont
contribuer à notre site ne voudront pas y passer trop de temps, j'essaye
de faire en sorte que le copier/coller d'un source TeX (enfin, de
l'intérieur d'un \begin{document}/\end{document}) dans l'interface
privée de SPIP marche à 99%. D'où le traitement des accents à la TeX par
SPIP etc, et la nécessité de pouvoir taper $x<y$ directement. Si
j'impose aux auteurs de taper <span class="math"> ou même \(\) personne
ne le fera.

En revanche, les formules n'apparaissent pas dans la partie privée du
site, et pour cause, le script (javascript) qui s'en charge n'est pas
chargé (il l'est dans la partie publique en rajoutant ce qu'il faut
dans les squelettes...)

Pas trop grave, tant que les formules apparaissent en prévisualisation
on peut faire avec ...

Solution de secours, en attendant mieux : j'ai rajouté une ligne à
ecrire/exec/articles.php pour charger jsMath, et cela marche...

C'est plus agréable ainsi je trouve...

J'hésite à toucher au contenu de ecrire/ ... Quand j'aurai un système
qui marchera correctement, j'irai voir dans les sources de quelques
plugins pour voir comment ils font - par exemple couteau suisse qui
introduit des blocs repliables qui apparaissent dans l'espace privé. La
balise #INSERT_HEAD est un bon début je dirais.

À la fin si tout se passe bien il y aura un plugin "jsMath", et on
n'aura plus à toucher aux squelettes ...

On en recause.

  /vincent

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25

Vincent Beffara a écrit :

(...) la nécessité de pouvoir taper $x<y$ directement. Si j'impose aux auteurs de taper <span class="math"> ou même \(\) personne ne le fera.

AMHA, il faut abandonner la notation $x<y$ car elle est trop difficilement traitable génériquement.
Il faut informer les rédacteurs par exemple d'ajouter un $ : $$x<y$$ ou $$$x<y$$$ pour un paragraphe. Dans ce cas la recherche par regexpr sera plus sûre et ce n'est pas un gros effort de rédaction..

Si tu utilises le Couteau Suisse, tu peux facilement te programmer une lame perso qui utilise un traitement pre_propre sur la balise #TEXTE, c'est peut-être plus efficace qu'un pipeline qui va s'appliquer sur toutes les chaines de SPIP.

Pat

Re-bonjour,

> (...) la nécessité de pouvoir taper $x<y$ directement. Si
> j'impose aux auteurs de taper <span class="math"> ou même \(\) personne
> ne le fera.

AMHA, il faut abandonner la notation $x<y$ car elle est trop
difficilement traitable génériquement.
Il faut informer les rédacteurs par exemple d'ajouter un $ : $$x<y$$ ou
$$$x<y$$$ pour un paragraphe. Dans ce cas la recherche par regexpr sera
plus sûre et ce n'est pas un gros effort de rédaction..

Je suis bien d'accord qu'en imposant ce genre de choses on peut parser
plus facilement (et dans ce cas j'imposerais une notation plus
asymétrique du genre $( $) voire, pour plaire aux TeXiens, on peut aussi
imposer ${x<y}$ qui a le bon goût d'être du TeX valide).

Seulement, encore une fois, je préférerais éviter d'informer les
rédacteurs - et on a une cinquantaine d'articles déjà écrits en LaTeX
(correspondant à des volumes papier précédents de "Images des
mathématiques"), un des buts que j'ai c'est d'en rendre l'importation la
plus simple possible, et idéalement possible par un bête copier-coller.
Le fait qu'un '$' isolé soit impossible, ça ne me gêne pas plus que ça,
les matheux étant conditionnés à taper \$ qu'on peut parser au départ.

[En plus, plus ce qu'on demande aux auteurs est différent de ce qu'ils
font tous les jours, moins on aura de contenu ...]

Tel que <math>$x<y$</math> fonctionne actuellement, on a déjà le
problème de parsing, d'ailleurs.

Si tu utilises le Couteau Suisse, tu peux facilement te programmer une
lame perso qui utilise un traitement pre_propre sur la balise #TEXTE,
c'est peut-être plus efficace qu'un pipeline qui va s'appliquer sur
toutes les chaines de SPIP.

Ah, merci du conseil, il faut que j'aille voir. Mais a priori, on voudra
que ça s'applique à la plupart des chaînes (au moins #TITRE, #SURTITRE,
#SOUSTITRE, #DESCRIPTION, #CHAPO, #PS et #NOTES en tout cas) ! [Et puis,
le code source du couteau suisse est déjà impressionnant, j'ai un peu
peur de m'y noyer.]

Tant que j'y suis à poser des questions aux experts : il y a un moyen
simple de dire "applique donc ce filtre à tous les champs, et si au
moins l'un d'entre eux est modifié, ajoute cette ligne dans l'en-tête de
la page" ? Parce que jsMath est un truc relativement gros, qui ralentit
le fonctionnement du site, alors autant ne le charger qu'en cas de
besoin ...

Merci à tous pour vos conseils, en tout cas.

  /vincent

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25

Hej,

J'ai posté les modifications sur mon site : http://www.mpkju.fr
pas de problème pour l'échappement des {} semble-t-il. (Voir la banque
d'exercices pour quelques exemples...)

Reste bloqué à l'affichage "loading jsMath" sauf pour les pages de
rubriques ... donc on voit du code TeX. (J'utilise Opera sous Solaris,
je sais que je cherche les ennuis, mais c'est pas entièrement ma faute.)

Bon, ce n'est pas dramatique, mais je confirme que l'ajout de jsMath rend
mon site inaccessible aux utilisateurs d'opera...
(Pas dramatique vu que si mes utilisateurs ont été capables d'installer
opera, alors ils seront aussi capables d'installer firefox !)

Il y en a qui préfèrent Opera :-p

En revanche, j'ai un curieux bug avec les navigateurs internet explorer,
avec jsMath qui se plaint en prétendant avoir été chargé depuis un autre
domaine, alors qu'il est obtenu avec un lien relatif... Peut-être qu'un
lien en dur marche mieux, je testerai plus tard.

Ton lien dit <SCRIPT SRC="../jsMath/easy/load.js"></SCRIPT> dans la page
http://www.mpkju.fr/spip.php?article137, le '..' est de trop ! Je dirais
src="/jsMath/easy/load.js".

Le .. me paraissait assez logique, vu que le code html où apparaît cette
ligne est dans le répertoire /squelettes (et cela marche avec safari et
firefox !) mais je reconnais que cela marche aussi sans, ce qui devient
très mystérieux pour moi...

le src est relatif à l'URL (le navigateur ne sait pas que tes squelettes
sont dans /squelettes !) donc relatif à http://www.mpkju.fr/. "/jsMath"
veut donc dire http://www.mpkju.fr/jsMath. J'ai eu un gag similaire de
jsMath qui se plante, que j'avais provoqué en remplaçant '' par un
chemin erronné dans easy/load.js (là aussi comme c'est le navigateur qui
voit les adresses, il faut que ça commence par "/jsMath" ...)

Cela n'a rien changé pour ce qui concerne opera qui semble planté au
chargement de jsMath...

J'ai laissé tomber les liens relatifs pour indiquer l'adresse complète, et
il y a un peu de mieux : internet explorer ne se plaint plus, et quant à
opera, la rubrique exercices s'affiche normalement lorsqu'on la sélectionne
la première fois...

En revanche, il plante encore lorsqu'on cherche à accéder à un exercice, et
je ne vois pas pourquoi...

Essaye toujours de remplir root dans easy/load.js par une adresse
explicite, on ne sait jamais ... Tu as un .htaccess avec réécriture
d'adresses (url propres, typiquement) ? dans ce cas il faut peut-être
traiter /jsMath séparément ?

Elle n'est pas forcément nécessaire, pourvu de suivre les < et >
d'espaces,
ce qui n'est pas une si grande contrainte je trouve.

Ah, ce serait vrai si c'était moi qui écrivais les articles, mais les
matheux ne sont pas des gens disciplinés. Comme les gens qui vont
contribuer à notre site ne voudront pas y passer trop de temps, j'essaye
de faire en sorte que le copier/coller d'un source TeX (enfin, de
l'intérieur d'un \begin{document}/\end{document}) dans l'interface
privée de SPIP marche à 99%. D'où le traitement des accents à la TeX par
SPIP etc, et la nécessité de pouvoir taper $x<y$ directement. Si
j'impose aux auteurs de taper <span class="math"> ou même \(\) personne
ne le fera.

Les environnements type \begin{enumerate} et consorts passeront aussi ?

Pour les itemize, on en obtient une approximation en remplaçant
simplement \item par un tiret en début de ligne, ça je pense que je le
ferai. Pour les enumerate il suffit d'utiliser -# mais après il faut
choisir lequel utiliser, ça risque de devenir un peu chevelu. Et puis
pourquoi pas les \begin{array} tant qu'on y est, ce serait utile aussi
(encore que moins). Non, sérieusement celui que je vais sans doute
implémenter c'est \begin{theorem} et consorts, parce qu'on en a un
paquet dans nos archives.

Un truc qui aiderait (ceci est une question pour les PHPexperts) : il y
a un moyen pas trop chiant de trouver l'accollade fermant une accollade
ouvrante donnée ? (en supposant qu'il n'y a pas de \})

Enfin si tu m'offres une bière (ou une bouteille, c'est plus dans ton
coin) on peut en causer ... Je ne me vois pas réimplémenter tout LaTeX
en PHP, mais pour des morceaux comme ça ponctuellement c'est faisable.

[Sinon, une idée serait d'exploiter TTH/TeX4HT/LaTeX2HTML/HeVeA mais ça
me semble un peu overkill, vu qu'on n'aura jamais de traitement 100%
automatique.]

Je tiendrai la liste au courant au fur et à mesure.

  /v

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25

Vincent Beffara a écrit :

Si tu utilises le Couteau Suisse, tu peux facilement te programmer une lame perso qui utilise un traitement pre_propre sur la balise #TEXTE, c'est peut-être plus efficace qu'un pipeline qui va s'appliquer sur toutes les chaines de SPIP.

Ah, merci du conseil, il faut que j'aille voir. Mais a priori, on voudra que ça s'applique à la plupart des chaînes (au moins #TITRE, #SURTITRE, #SOUSTITRE, #DESCRIPTION, #CHAPO, #PS et #NOTES en tout cas) ! [Et puis,

Ah oui, en effet, autant garder le pipeline alors !!

[Et puis, le code source du couteau suisse est déjà impressionnant, j'ai un peu peur de m'y noyer.]

Les détails sur les lames perso sont ici :
  [dev] Le Couteau Suisse à piloter - SPIP-Contrib

C'est pas très compliqué, je reste à l'écoute des question éventuelles, et ça permet de faire des tests rapides, sans forcément construire un plugin en bonne est due forme.
(petit rappel : pour compiler le CS suite à un changement, il faut se rendre (ou réafficher) la page de config privée du CS)

Tant que j'y suis à poser des questions aux experts : il y a un moyen simple de dire "applique donc ce filtre à tous les champs, et si au moins l'un d'entre eux est modifié, ajoute cette ligne dans l'en-tête de la page" ? Parce que jsMath est un truc relativement gros, qui ralentit le fonctionnement du site, alors autant ne le charger qu'en cas de besoin ...

A voir : le pipeline 'affichage_final' ou une astuce en jQuery du genre : "si on trouve une certaine classe, on lance le fichier .js"

Sous SPIP SVN, il ya les pipelines 'insert_js' et 'verifie_js_necessaire', mais je n'ai pas encore étudié leur fonctionnement.

Pat

Bonjour à tous,

Je tiendrai la liste au courant au fur et à mesure.

OK, on progresse. Je mets une version préliminaire (mais déjà
fonctionnelle) de mon plugin jsMath sur ma page web ici :

  http://www.umpa.ens-lyon.fr/~vbeffara/files/jsMath-0.2.zip

Pour l'instant, voici ce qu'il fait sur les maths :

- attraper les maths (délimitées par des $..$, $$..$$, \(..\) et
  \[..\]) ; comme TeX, ça ne fonctionne que si les dollars sont
  appariés. Ça veut aussi dire que pour faire un vrai dollar dans le
  texte, il faut un peu jongler et dire un truc du genre
  <html>\$</html>.
- dedans, remplacer les '<' par des '&lt;' pour faire du XHTML valide ;
- les redélimiter systématiquement par des dollars (mais en fait ce
  serait peut-être plus propre avec des <span class="math"> ? perso je
  mets tex2math et autoload sur jsMath, et je trouve les dollars plus
  lisibles, mais vu le premier point, je vais sans doute changer d'avis) ;
- protéger tout ça par une balise SPIP <html> et appeler echapper_html
  (pour empêcher les accolades de TeX d'êtres interprétées par SPIP).
  L'encodage explicite est nécessaire parce que pre_typo a l'air d'être
  appelé deux fois (avant typo et avant propre) ?

Le tout, dans le pipeline pre_typo, donc ça s'applique à tous les
champs, et dans le pipeline affiche_milieu pour l'espace privé. Les
maths fonctionnent aussi dans les forums, mais pas dans leur gestion
dans l'espace privé ...

Le plugin ajoute aussi la ligne qui appelle easy/load.js dans l'entête
de page (à condition bien sûr que le squelette contienne #INSERT_HEAD).
Il utilise SPIP pour trouver ce fichier, donc il faut que le répertoire
jsMath soit visible - moi je l'ai mis à la racine du site, mais on peut
aussi le mettre dans squelettes/. Une autre solution serait de le mettre
directement dans le répertoire du plugin (en fait c'est dans cette
optique que j'ai fait un plugin séparé plutôt qu'une lame perso du
couteau suisse) mais ça fait une archive de 6 Mo ...

Le plugin présuppose que les options "tex2math" et "tex2math_dollars"
(ou quel que soit son nom) soient activées. "autoload" fonctionne
aussi.

Dernière chose, le plugin essaye de traiter quelques commandes TeX qui
resteraient d'un copier-coller. Pour l'instant,

- les accents (\'e etc.)
- \emph, \textbf, \section
- \ldots
- et on enlève brutalement \medskip, \newblock, \noindent ...

J'en ajouterai au fur et à mesure si j'en ai besoin.

Voila voila, j'espère que ce sera utile à quelqu'un.

A+,

  /v

--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25