Bonjour
Depuis plusieurs semaines, je n’arrive plus à générer les images en latex.
L’image PNG est créée en local mais elle est erronée et contient le texte :
404 Not FoundThe requested URL /tex.php was not found on this server.
Le site https://math.spip.net/ n’est PAS accessible
et https://latex.spip.net est bien actif mais le script tex.php est introuvable.
MERCI pour votre aide.
Bonjour
Merci pour le retour, je n'avais pas identifié cet usage. J'ai corrigé
le service.
Est ce que cela fonctionne mieux ?
Km
Y’a du mieux. Le script est désormais accessible mais il semble qu’il soit mal configuré ?
Une image PNG est bien générée mais au lieu de contenir la formule mathématique en clair, elle représente une suite de caractères (fichier en PJ).
Bonjour
Pour les test peux tu donner une url à essayer. La capture d’écran pour ce point n’est pas pratique.
Merci
Km
Bonjour tout le monde
Le serveur latex continue à dysfonctionner, n'utilisant pas la
fonctionnalité en soit j'ai du mal à identifier le problème.
Est ce que d'autres personnes font pareil que bruno et ont des
problèmes de rendu ?
Merci pour votre aide,
Km
Bonsoir
Toujours pas d’améliorations.
Je vais essayer de me débrouiller en installant le script sur mon serveur. Mais c’est dommage pour SPIP, cela signifie que la fonctionnalité LATEX n’est plus opérationnelle.
Il y a une doc ici
https://contrib.spip.net/Serveur-TeX
mais peut-être elle n’est plus à jour ou il faut corriger des choses ?
Bruno si tu as quelques chose de fonctionnel en local tu peux peut-être nous faire un feedback sur comment tu as fait qu’on mette à jour la doc et rétablisse le service sur le serveur de SPIP ?
Bonjour,
Je ne connais pas la fréquence de mise à jour du cache des inclusions en latex dans les articles.
J'ai un article avec l'inclusion suivante :
<math>
$ Igz= \pi \times d^{4} \times \frac {1}{64} $
</math>
Qui fonctionne en SPIP 3.2.1 .
La fréquence de mise à jour du cache article est 24h00 (j'ai désactivé le recalcul systématique à l'édition).
Cela fonctionnait donc au moins jusqu'en décembre 2017, date à laquelle j'ai migré le site de SPIP 1.8.3 à 3.1.7 et où le cache image a été reconstruit - j'ai depuis suivi les MAJ : 3.2.0, 3.2.1 - l'affichage des inclusions LATEX est toujours effectif .
Cordialement,
Eric
Cela fonctionnait donc au moins jusqu'en décembre 2017, date à
laquelle j'ai migré le site de SPIP 1.8.3 à 3.1.7 et où le cache
image a été reconstruit - j'ai depuis suivi les MAJ : 3.2.0, 3.2.1 -
l'affichage des inclusions LATEX est toujours effectif .
Je suis allé voir dans le cache : local/cache-TeX : les vignettes ont
été mise à jour le 17 mars 2018 pour la dernière fois.
Cordialement,
Eric
Le piège ici c’est que SPIP garde les images générées par le serveur Latex ad vitam tant que la formule ne change pas. Ce sont donc des vieilles images que tu as là
Si je teste sur un SPIP 3.2.1 je confirme deux problèmes :
* l’image renvoyée est un GIF au lieu d’un PNG, ce qui provoque une erreur de traitement d’image par la suite (mais c’est peut-être un bug conséquence du suivant)
* le résultat dans le GIF est incorrect :
Salut
Si je teste sur un SPIP 3.2.1 je confirme deux problèmes :
* l’image renvoyée est un GIF au lieu d’un PNG, ce qui provoque une erreur
de traitement d’image par la suite (mais c’est peut-être un bug conséquence
du suivant)
Merci bien vu, la documentation indique que c'est un png qui sort par
défaut. J'ai corrigé pour forcer le type
* le résultat dans le GIF est incorrect :
Ok compris les caractéres encodées sont traitées tels que, j'ai modifié
pour restaurer la chaîne de texte
Pour moi maintenant cela fonctionne :
Est ce mieux pour vous ?
Km
C'est bon l'image est générée.
Par contre le fond est transparent, il était blanc.
Merci.
Bon, j’ai essayé d’installer le truc sur mon serveur et je tombe sur un bug de pdflatex. la commande
latex -interaction=batchmode out.tex > /dev/null
est lancée dans le script text2im, vers la ligne 200.
Elle renvoie un code 134, SIGABRT ce qui indique que la commande s’est plantée (en fait, pdflatex plus exactement).
Alors que la même commande lancée de la console fonctionne parfaitement.
Peut-être que c’est le même bug qui se retrouve sur le serveur officielle de SPIP ? peut-être un bug qui vient d’être introduit dans pdflatex ?
A partir de là, je sèche.
ca m'étonnerai mais rien n'est exclu. ?A ma connaissance, la fonction de mise en page de formule n'a pas changé dans pdftex depuis belle lurette, et latex n'ajoute rien à ca.
Quel est ta texlive? peux tu m'envoyer le out.tex?
Bonjour Maïeul
Voilà ce que j’ai pour texlive : texlive:all/jessie 2014.20141024-2+deb8u1 uptodate
Comme demandé, j’ai mis un exemple de out.tex en PJ.
Si je lance la commande directement depuis la console : latex -interaction=batchmode out.tex > /dev/null
cela fonctionne. Le fichier DVI est bien généré.
Cette même commande, lançée depuis text2im se plante, aucun message d’erreur. Juste une sortie avec signal 134.
Si dans text2im, je remplace cette ligne par : latex -help
Ça plante pas et cela génère bien l’aide en sortie.
out.tex (470 Bytes)
Bon, testé chez moi (avec une TexLive 2018 "vanille") > le .div puis le .eps marche parfaitement. Et pour autant que je connaisse le monde LaTeX, il y a rien eu dans pdtex/pdflatex/latex ces 4 dernières annèes qui pourraient expliquer un changement entre toi et moi, surtout vu la simplicité de fichier .tex
Par contre cela plante chez moi au moment de convert. Les dernières versions de convert n'autorise pas, par défaut, pour des raisons de sécurité, de transformer un pdf/ps.
Donc c'est peut être cela chez toi.
Maïeul
Les dernières versions de convert n’autorise pas, par défaut, pour des raisons de
sécurité, de transformer un pdf/ps.
Donc c’est peut être cela chez toi.
Non cela n’est pas cela. J’en suis sûr. le script n’arrive même pas à cette étape de convert. Il s’agit bien de la commande latex qui plante, qui fait un ABORT (signal 134). J’ai testé le processus dans tex2im, en placant des exit ligne par ligne pour voir ce qu’il en sort à chaque étape.
Et j’arrive à la ligne 200 de tex2im : latex -interaction=batchmode out.tex > /dev/null
qui devrait produire un fichier out.dvi
lequel out.dvi est traité ensuite par une commande dvips qui convertit le fichier DVI en EPS. Mais cela ne fonctionne pas puisque le fichier n’a pu être créé par la commande latex précédente.
Le truc bizarre, c’est que la commande “latex -interaction=batchmode out.tex” lançée depuis la console, fonctionne parfaitement bien, le DVI est bien produit.
Mais lançée depuis tex2im => erreur 134.
Je constate que le serveur LATEX officiel de SPIP est de nouveau opérationnel. MERCI à tous ceux qui l’ont remis sur pied.
De mon côté, je n’ai pas réussi à le faire fonctionner sur mon serveur. C’est frustrant. Mais je n’ai pas le temps d’approfondir.
Salut
Je constate que le serveur LATEX officiel de SPIP est de nouveau opérationnel. MERCI à tous ceux qui l'ont remis sur pied.
Merci d'avoir remonté les problèmes et fait tous les tests utiles.
De mon côté, je n'ai pas réussi à le faire fonctionner sur mon serveur. C'est frustrant. Mais je n'ai pas le temps d'approfondir.
Rassures toi comme tu as pu le voir ce n'est pas évident. Sur le
serveur SPIP on n'utilise plus latex (car les paquets pour générer les
images ne sont plus en paquet standard). On a contourné le problème en
s'appuyant sur le script minimal mimetex (
Debian -- Package Search Results -- mimetex ) couplé à convert
pour avoir du png
Il n'est pas aussi complet mais il fait le boulot 
Pour le fond transparent, je pense que cela va rester en l'état. Il
est plus souple de mettre à jour sa CSS pour activer un fond de la
couleur voulue.
Km
Pour le fond transparent, je pense que cela va rester en l'état. Il
est plus souple de mettre à jour sa CSS pour activer un fond de la
couleur voulue.
OK
Merci.
