Version PDF avec SPIP2LaTeX

SPIP2LaTeX converti le langage de marquage de SPIP en LaTeX. Utilisé avec une installation de LaTeX, il permet de produire des versions PDF des articles d’un site.

Le style par défaut des PDF produits est peu excitant, l’usager final voudra sans aucun doute procéder à une personnalisation.

Voir un exemple de beau PDF.

Configuration du serveur web

Le serveur web doit avoir la commande pdflatex dans son PATH. SPIP doit aussi être capable de charger les URL  ?page=latex (voir ci-dessous) depuis localhost. Ceci requiert allow_url_fopen=true dans php.ini et un accès anonyme autorisé depuis 127.0.0.1

URL introduites par le plugin

Version LaTeX d’un article ou d’une rubrique :

  http://www.example.net/?page=latex&id_article=4
  http://www.example.net/?page=latex&id_rubrique=7

Version PDF d’un article ou d’une rubrique :

  http://www.example.net/?page=pdf&id_article=4
  http://www.example.net/?page=pdf&id_rubrique=7

On peut aussi ajouter la ligne suivante tout au début du squelette
article.html pour obtenir la version PDF en ajoutant  ?formatpdf=1 a
la fin de l’URL d’un article.

[[(#INCLUDE{fond=latex/document.tex,env}|
	spip2latex_pdf{[(#ENV**|unserialize)]})](#ENV{formatpdf})]

Modèles introduits par le plugin

Faire un lien vers la version PDF d’un article ou d’une rubrique avec un modèle :

  <pdf0|id_article=4>
  <pdf0|id_rubrique=7>

On peut aussi faire le lien dans un squelette, avec la balise #MODELE :

  [(#MODELE{pdf}{id_article=#ID_ARTICLE})]

Pour personnaliser l’affichage, il faut appliquer des styles CSS à la classe .spip2latex_pdf

Personnalisation des PDF produits

Le squelette latex.html utilise #INCLURE sur latex/document.tex.html, qui utilise à son tour #INCLURE sur les noisettes suivantes :

  • latex/preambule.tex.html avant \begin{document}
  • latex/entete.tex.html après \begin{document} mais avant le contenu
  • latex/pied.tex.html après le contenu mais avant \end{document}

Il faut surcharger ces noisettes pour personnaliser l’affichage des PDF produits. latex/preambule.tex.html est particulièrement intéressant à ce titre, car c’est là que sont définis les styles des éléments traduits depuis SPIP. Voici les commandes et environnements LaTeX candidats à la surcharge :

Environnements LaTeX utilisés par SPIP2LaTeX
environnements LaTeXUsage
spiptolatexthead Titre de colonne de table
spiptolatextsummary Description de table
spiptolatexexergue Pour [* Texte mis en evidence *]
spiptolatexaltexergue Pour [** Texte mis en evidence (alternatif) *]
spiptolatexquote Pour <quote>Citation</quote>
spiptolatexcadre Pour <cadre>Texte encadré</cadre>
spiptolatexpoesie Pour <poesie>Poésie</poesie>
spiptolatexcode Pour <code>Code source</code>
spiptolatexright Pour [/ Alignement à droite /]
spiptolatexcenter Pour [| Centrage |]

Langue et jeu de caractère

Les squelettes de base de SPIP2LaTeX tentent de configurer la langue et le jeu de caractère. Seules ont été testées pour l’instant les associations de français et anglais d’une part, et ISO-8859-1 et UTF-8 d’autre part.

Pour ce qui est de la langue, le filtre spip2latex_lang tente de convertir le code langue ISO de l’article en option de langue pour le paquetage babel. Si une langue ne passe pas, il est toujours possible de surcharger latex/preambule.html, mais il serait encore mieux de modifier le filtre spip2latex_lang dans le fichier spip2latex.php et de contribuer la modification, pour que les autres en profitent.

Le jeu de caractère de sortie est par défaut ISO-8859-1. Un formulaire CFG permet de configurer globalement un autre jeu de caractère. Il est aussi possible de remplacer dans un squelette le jeu de caractère par défaut, en utilisant la balise #SPIP2LATEX_CHARSET.

Invoquée avec un argument, elle permet de fixer le jeu de caractère de sortie de SPIP2LaTeX, c’est ce qui est fait dans le squelette latex/document.tex.html, mais on la ré-invoquer dans une noisette si on le souhaite, pour choisir un autre jeu de caractères. Utilisée sans argument, elle renvoie le jeu de caractère courant. Le squelette latex/preambule.html l’utilise sans argument, pour configurer le paquetage inputenc avec le jeu de caractère courant.

Le jeu de caractère de sortie de SPIP2LaTeX n’est pas contraint par le jeu de caractère utilisé par SPIP. Une conversion aura lieu si nécessaire.

Il arrive de temps en temps qu’un caractère un peu exotique empêche LaTeX de compiler le PDF. La balise #SPIP2LATEX_UNICODE_FILTER permet d’indiquer quels points de code UCS doivent être filtrés. Le formulaire de configuration de SPIP2LaTeX permet d’indiquer sa valeur par défaut.

Un exemple pour éliminer tout ce qui pose problème quand on travaille sur une langue latine :
0x0000-0x001f,0x007f0x009f,!0x000d,!0x000a,0x0126,0x0127,0x0138,0x013f,0x0140,0x0149,0x0166,0x0167,0x017f-0xffff

Production de code LaTeX par les modèles

Lorsqu’un modèle <trucXX> est rencontré, SPIP2LaTeX utilise modeles/latex_truc.html pour obtenir du code LaTeX. Le plugin fournit des modèles pour <docXX> et <imgXX>, qui peuvent être
surchargés en redéfinisant les fichiers modeles/latex_doc.html et modeles/latex_img.html

Vous devez produire des versions LaTeX pour vos modèles personnalisés.

Raffraîchir le cache

Les pages  ?page=latex&id_article=xxx ne sont pas cachées. Les squelettes qui les construisent voient en revanche leur forme compilée tomber dans le cache. Il est donc nécessaire de recharger  ?page=latex&id_article=xxx&var_mode=recalcul après avoir modifé latex/(preambule|entete|pied).tex.html

Les PDF générés sont cachés jusqu’à ce que l’article ou la rubrique correspondant soit calculé, ce qui se produit normalement après qu’un utilisateur l’ait modifié. Il est aussi possible de purger le cache d’un PDF en ajoutant  ?var_mode=calcul à l’URL qui permet de le télécharger.

Discussion

18 discussions

  • Voici SPIP2LaTeX version 1.5.5

    Suite à une migration en tout UTF-8, nous avons eu besoin de filtrer les caractères Unicode posant problème. On fait ça avec le point de code au format UCS. La documentation et le présent article ont été mis à jour pour documenter cela.

    Répondre à ce message

  • Je viens de publier SPIP2LaTeX 1.1 :

    • on ajoute un argument var au filtre spip2latex, pour produire un nom de fichier différent et ainsi avoir plusieurs versions en cache. var est utilisé pour produire la hash du nom du fichier en cache :
      spip2latex_pdf(#ENV**, passes, var
    • L’environnement de spip2latex_pdf peut inclure une variable fichier dont la valeur est utilisée pour déterminer le nom du fichier présenté au navigateur.

    Répondre à ce message

  • 1
    Christophe

    Bonjour,

    je suis un ultra newsbie en Spip (2.1.11), ça c’est dit.
    Pour m’excercer je l’ai installé en local sur lampp Ubuntu.

    J’aurais 2 questions en amont :

    1. lors de la configuration du serveur web : qu’entendez-vous par

      Le serveur web doit avoir la commande pdflatex dans son PATH ?

    2. comment faut-il s’y prendre pour donner

      accès anonyme autorisé depuis 127.0.0.1 ?

    Enfin, j’ai tenté d’installé le plugin, et d’éditer un article de test avec le modèle :

    [(#MODELE{pdf}{id_article=#ID_ARTICLE})]

    Lorsque je clique sur l’icône pdf, j’obtiens l’erreur suivante :

    <b>Warning</b>:  readfile(/opt/lampp/htdocs/spip/tmp/cache/latex/article1/27bd4e247abb2ff99c6e4d697d8d052e2d3b6b20.log) [<a href='function.readfile'>function.readfile</a>]: failed to open stream: Aucun fichier ou dossier de ce type in <b>/opt/lampp/htdocs/spip/plugins/auto/spip2latex-1.0.1/spip2latex.php</b> on line <b>1406</b><br />

    J’ai parcouru en vain le forum ainsi que Big G pour trouver les solutions à ces problèmes.
    Donc, si une âme charitable pouvait ne serait-ce que me donner une petite piste, je ne cherche pas à ce qu’on me mâche le travail, hein, ce serait bienvenu !

    Merci d’avance.

    • Christophe

      Re bonjour,

      je fais suite à mon poste, car depuis mes investigations, apparement il n’y pas de fichier *.log généré dans le dossier /tmp/cache/latex/ mais un fichier avec l’extension *.tex .

      Je penche de plus en plus vers un problème de PATH sur le serveur web (dans mon cas en locale avec Lampp) qui n’aurait pas accés à pdflatex.

      Je continue de chercher, mais bien sûr, un regard / une aide extérieur(e) serait bienvenu :)

      Merci

    Répondre à ce message

  • 3

    salut
    je suis sous spip 2.1.10 derniere version a cette date, j’ai l erreur suivante en click sur le lien pdf
    Warning : filesize() [function.filesize] : stat failed for /home/dinebout/public_html/pwwo/tmp/cache/latex/article6/e24f1000e64d0dfeb9213c5a402ed0571bcb6f79.log in /home/dinebout/public_html/pwwo/plugins/spip2latex-1.0.1/spip2latex-1.0.1/spip2latex.php on line 1402

    Warning : Cannot modify header information - headers already sent by (output started at /home/dinebout/public_html/pwwo/plugins/spip2latex-1.0.1/spip2latex-1.0.1/spip2latex.php:1402) in /home/dinebout/public_html/pwwo/plugins/spip2latex-1.0.1/spip2latex-1.0.1/spip2latex.php on line 1404

    Warning : Cannot modify header information - headers already sent by (output started at /home/dinebout/public_html/pwwo/plugins/spip2latex-1.0.1/spip2latex-1.0.1/spip2latex.php:1402) in /home/dinebout/public_html/pwwo/plugins/spip2latex-1.0.1/spip2latex-1.0.1/spip2latex.php on line 1405

    Warning : readfile(/home/dinebout/public_html/pwwo/tmp/cache/latex/article6/e24f1000e64d0dfeb9213c5a402ed0571bcb6f79.log) [function.readfile] : failed to open stream : No such file or directory in /home/dinebout/public_html/pwwo/plugins/spip2latex-1.0.1/spip2latex-1.0.1/spip2latex.php on line 1406

    l’instalation spip est dans un sous domaine, pas de serveur.

    • Le fichier de log de LaTeX n’a même pas été créé, cela suggère que SPIP n’a même pas réussi à exécuter la commande pdflatex. Est-ce que le champ « Commande LaTeX » du formulaire CFG est bien renseigné avec quelque chose de raisonnable ? Est-ce que le serveur web a bien les droits d’exécuter la commande ?

    • JE SUIS sous hebergement mutualisé, commade renseigné pdflatex
      merci

    • C’est à l’hébergeur qu’il faut le demander. Mais est-ce que LaTeX est même installé sur ce serveur ?

    Répondre à ce message

  • 5

    Nouvelle version 1.0.1, corrigeant deux bugs

    • Une virgule dans le titre cassait la compilation LaTeX (\hypersetup prends ça pour un séparateur d’arguments)
    • les descriptifs d’images n’étaient pas pris en compte
    • salut,

      par rapport à cela justement, je suis en train de créer un nouveau plugin qui ferait la même chose, à deux différences prés :
      -  il ne se chargera pas de la compilation en LaTeX, mais simplement de transformer du code spip en code LaTeX.
      -  il se base sur l’API Textwheel incluse dans SPIP 3 pour formaliser les transformation à operer.

      Par ailleurs il se trouve sur la zone (encore en cours de dev)

    • TextWheel pour réinventer la roue, en somme ? :-)

    • pas seulement, aussi pour avoir quelquechose de structuré et facilement maintenable par d’autres.

    • Je suis curieux de voir le résultat. Ma conclusion personnelle est qu’en l’absence d’une grammaire non ambigüe il est impossible de mener à bien la phase d’analyse syntaxique proprement. On est obliger de faire comme dans le noyau de SPIP, à savoir des enchainement de regex plus ou moins cabalistiques, et clairement peu maintenable. Mais j’adorerais avoir tort.

    • sans doute, sans doute. Mais simplement depuis la 3.0 les raccourcis typo de spip sont passé en TexWheel et je m’aligne donc là dessus.

      Ceci dit, du peu que je vois pour le moment, effectivement on a encore pas mal de regexp cabalisitiques.

    Répondre à ce message

  • 6

    Et voila notre version 1.0, soit-disant stable. Normalement c’est l’instant où une horde de nouveaux venus débarquent, testent le plugin, et trouvent une montagne de bogues :-)
    Nouveautés depuis 0.9.9
    -  Gestion des liens internes sans titre : on prend le titre de l’objet
    -  Configuration CFG pour indiquer a quelle longueur on tronque les URL
    -  C’est la 1.0

    Les prochains développements vont tourner autour de l’export de site entier, avec intégration du travail déjà fait par Matthieu à ce sujet, et la gestion des références.

    • Si ça peut être utile je viens de tomber sur cette nouvelle classe php :

      Elle génère du pdf en prenant en compte utf8 RTL les langages de programmation ...

    • Sans vouloir dévaloriser le travail fait dans le cadre du projet TCPDF, qui est sans aucun doute excellent, c’est un projet de plus pour produire du PDF, qui se confronte au même problème que les autres : faire un PDF ça n’est déjà pas trivial, mais faire une bonne mise en page, c’est beaucoup plus difficile.

      En la matière, le logiciel le plus avancé est sans aucun doute LaTeX, et de très loin. On peut lui reprocher la syntaxe cryptique de son langage et sa difficulté d’apprentissage, mais il bénéfice tout de même de 26 ans de recul en matière de mise en page.

      Le plugin SPIP2LaTeX fait le choix de s’appuyer sur LaTeX, pour une flexibilité et une qualité maximum dans le rendu des PDF. Le prix est la connaissance de LaTeX, qui n’a pas la courbe d’apprentissage la plus conviviale qui soit.

    • Corrobori

      OK,

      Je pensais que cette classe intervenait après la compilation par Latex et qu’elle ne dispensait pas de Latex. Au temps pour moi.

    • SPIP2LaTeX transforme la typo SPIP en LaTeX, et utilise la commande pdflatex de LaTeX pour en faire du PDF. Aucune librairie ou extension PHP n’est requise.

      Ce projet semble faire du PDF depuis de l’HTML, ce qui suggère qu’on pourrait faire un autre plugin, qui transformerait la typo SPIP en HTML (en fait c’est SPIP qui fait ça), et utiliserait TCPDF pour faire du PDF.

    • Le prix est la connaissance de LaTeX, qui n’a pas la courbe d’apprentissage la plus conviviale qui soit.

      Soit. Passer par Latex me parait être le meilleur moyen de générer des notes de marges. Peut on imaginer qu’à partir d’une div comme encart on génère du marginpar{} ?

      Quelque chose comme spip2latex modeles/latex_encart qui fasse \marginpar #TEXTE  ?

      Je pense qu’il y a une façon élégante d’introduire les notes de marges dans SPIP par le biais du PDF. Tant qu’on reste dans le flux html on se contente d’un joli encadré stylé à son goût.

    • Oui, tu peux tout à fait envoyer en marge les <cadre>texte encadré</cadre> ou les [** texte en exergue **], par exemple. il suffit de redéfinir spiptolatexcadre ou spiptolatexaltexergue.

    Répondre à ce message

  • 3

    Version 0.9.9
    -  Ne pas garder les numéros de classements dans les noms des PDF
    -  Gestion de cache : on purge les PDF des que la base est modifiée
    -  Echappement correct des URL de glossaire, gestion de versions raccourcies
    -  Les listes numérotés fonctionnent
    -  Affichage correct du code PHP invalide dans les cadres

    Histoire de tenter un peu le diable, je l’ai marquée « stable »

    • Bon... ça devient bien là...
      Reste juste un soucis que je vois en regardant le PDF généré. Un texte tel que :

      Voir : [->art8], [->art9], [->art10]

      Génère : Voir : 1, 2, 3.
      Où 1, 2, 3 sont des notes en bas de page où l’URL est affichée.
      Cela devrait afficher : Voir : titre de l'article 1, titre de l'article 2, titre de l'article 3
      Où 1, 2 et 3 sont toujours les liens en bas de page.

      Autre chose, certains liens qui sont long sont coupés dans les notes en bas de page. Or, ce qu’on demande à un PDF, c’est de pouvoir être imprimé (il me semble), du coup, couper le texte des liens ne me parait pas pertinent, vu qu’une moitié de lien imprimé amène à un 404 inévitablement :)

      Du moins... une option pourrait nous départager :)

    • Pour les liens vers des articles internes, en fait si il n’y a pas de texte du lien on doit prendre le titre de l’article ? Pas de soucis.

      Pour les troncatures d’URL, le mieux que je puisse proposer, c’est de rendre la longueur configurable via CFG, avec 0 pour ne pas tronquer. Mais bon les URL interminable, personne ne les recopie, hein...

      • pour les liens internes, oui, c’est cela
      • pour les troncatures... tu as raison, je pense que l’option que tu proposes n’est pas mal :)

      Il va me rester 1 soucis ensuite. C’est que pour certains PDFs, les liens vers les articles doivent être externes (une URL est donc affichée) mais pour certains autres, qui contiennent, eux, par exemple l’intégralité des articles du site, les liens vers les articles doivent être internes au PDF, c’est à dire afficher le numéro de la page correspondante. Je me demande si une option au filtre |spip2latex_pdf{} ne pourrait pas dire cela... peut être que je me trompe.

      En tout cas, merci, les problèmes disparaissent les uns après les autres :)

    Répondre à ce message

  • 7

    Nouvelle version 0.9.6, avec plein de trucs chouettes

    • Tout le jeu de caractere latin-1 peut etre utilise sans erreur
    • Ajouter la connaissance de latin-9
    • Formulaire CFG pour indiquer la commande pdflatex (ou xetex...)
    • Usage du cache SPIP pour les PDF
    • Correction pour le glossaire quand il y a des #

    Attention, pour ceux qui s’étaient fait une version PDF lorsque l’URL finii en  ?formatpdf=1, il y a un changement. On ne dit plus

    [(#ENV{formatpdf}|?{#SPIP2LATEX_PDF_OUTPUT{#URL_PAGE{latex}|
            url_absolue|parametre_url{id_article,#ID_ARTICLE}}})]

    Mais on dit :

    [[(#INCLUDE{fond=latex/document.tex,env}|spip2latex_pdf)](#ENV{formatpdf})]

    Dernier point, pour Matthieu : je n’ai pas trop compris l’objet de ta contribution $href = str_replace('#', '@\\#', $href);, je l’ai intégré, mais je me demande si il ne faudra pas le même type de traitement pour d’autres caractères spéciaux LaTeX, comme _ % ou &

    • Bien, je vais tester.

      Par rapport à ma ligne sur $href, c’est bien possible que ma correction soit insuffisante.

      Je te propose également d’éviter $GLOBALS['contexte'] dans spip2latex_pdf de la sorte :

      [(#INCLURE{fond=latex/document.tex,env}|spip2latex_pdf{ [(#ENV**|unserialize)] })]

      Et

      function spip2latex_pdf($texte, $contexte) {
    • Bien, déjà, toutes les erreurs que j’avais pu avoir sont corrigées par cette version, c’est extra ! Merci donc :)

      Je vais donc tenter d’aller un peu plus loin en exportant toute une rubrique... si j’y arrive :)

    • Coquille :

      function spip2latex_traiter_raccourcis_glossaire($texte) {
      -	include_spip('inc_lien');
      +	include_spip('inc/lien');

      J’ai un soucis dont je ne retrouve pas l’origine, sur [(#TEXTE**|spip2latex)] lorsqu’un article possède un glossaire [?mot#trac], il me dit que la fonction de l’extension « code » pour le porte plume nommée « glossaire_trac » est déjà définie, alors même que je vérifie justement son éventuelle existence avant, et que en théorie ce fichier n’est appelé qu’une seule fois (http://zone.spip.org/trac/spip-zone/browser/_plugins_/porte_plume_extras/codes/pp_codes_fonctions.php#L15). Si je mets[(#TEXTE*|spip2latex)], cela passe. Je vais essayer de poursuivre mes recherches.

    • Pour href, tu pourrais essayer de faire les mêmes échappements que dans spip2latex_escape_latex0 (en ajoutant l’@), pour voir si ça continue de marcher ?

      Pour le $GLOBALS["contexte"], on doit déjà se le farcir pour spip2latex_insert_head, du coup ça motive moins pour s’en débarrasser. En tout cas ça m’aura appris que ENV c’est $GLOBALS["contexte"], je n’ai pas perdu ma journée.

      Pour le #TEXTE**, pour rappel, on a vraiment besoin de la double étoile pour pouvoir afficher <?php dans un bloc de code.

    • Compris !

      C’est cet article qui fait planter : http://programmer.spip.org/Ajouter-un-type-de-glossaire

      En fait... le PHP est exécuté !
      Voilà qui nous met dans l’embarra !

    • Je viens de tester pour $href latex0 (sans modification) et ça semble fonctionner :

      			$href = extraire_attribut($ref, 'href');
      +			$href = spip2latex_escape_latex0($href);
      -			$href = str_replace('#', '@\\#', $href);
    • Concernant spip2latex_insert_head(), cet appel n’a pas sa place à mon avis.
      Il vaut mieux le faire dans spip2latex_pdf(), en passant $contexte dedans. Au passage, je ne vois pas pourquoi ne supprimer que les PDF de l’article en train d’être visité : si c’est pour qu’il ait son PDF à jour, c’est déjà le cas en utilisant le cache de SPIP et la fonction spip2latex_pdf(). Si c’est pour enlever de vieux PDFs qui ne sont potentiellement plus à jour, autant supprimer tout le répertoire latex/.

      Je proposerais donc de supprimer tous les PDF dès que la date de modification de SPIP a changé (donnée par $GLOBALS['meta']['derniere_modif'] qui serait à stocker par exemple dans spip2latex/date_purge).

      Ainsi, même lorsqu’un PDF ne dépend pas directement d’un article (par exemple là, j’essaie d’exporter tout le site en PDF), mon PDF doit se recalculer (ça il le fait déjà) et supprimer les anciens (alors même que le PDF n’est pas stocké dans latex/articleNN donc)

      Je sais pas si je suis très clair dans mes explications.


      Bon, par contre, va falloir trouver une solution pour faire soit fonctionner [(#TEXTE*|spip2latex_pdf)], soit [(#TEXTE**|...)] en créant une fonction à peu près équivalente à interdire_script de SPIP pour latex... J’ai aussi d’autres catastrophes sur des articles ayant des codes PHP intégrés pas tout à fait valide.

      Exemple dans le texte d’un article (avec le cadre de classe php) (à appeler avec ?page=latex&id_article=117&var_mode=recalcul) :

      <?php
      	tu_plantes();
      ?>

    Répondre à ce message

  • 16

    Nouvelle version 0.9.4

    • gestion correcte de la ligature du œ
    • formulaire CFG pour indiquer l’encodage de sortie
    • la sortie UTF-8 fonctionne (NB : on sucre les accents dans les listings)
    • la langue est donnée au paquetage babel à partir de la langue de l’article

    Ma liste de problèmes à corriger est vide, hormis la demande de Matthieu concernant les modèles latex non trouvés, pour laquelle je ne suis pas certain de la bonne route à prendre. Peut être faudrait-il que ce soit configurable.

    • Je testerai dès que j’ai un peu de temps, pour vous ajouter quelques bugs :)
      Ce serait dommage que vous vous ennuyiez !

      Matthieu ^^

    • Bien...

      Alors, quelques remarques :

      • le formulaire CFG fait appel à IMG/spip2latex24.png. Ou a #DOSSIER_SQUELETTES/../IMG/spip2latex.png, ce qui n’est pas correct. Il faut utiliser #CHEMIN{IMG/spip2latex.png}, mais il vaudrait mieux nommer le répertoire « images » ou « img » pour éviter la confusion avec IMG/ du site SPIP
      • j’obtiens l’erreur sur ?page=latex&id_article=120 : Missing argument 1 for spip2Latex_charset() alors même que je l’ai déclaré « utf-8 » et validé le formulaire CFG. L’erreur vient de \usepackage[#SPIP2LATEX_CHARSET]{inputenc} dans le préambule, qui n’a pas le charset passé en paramètre de la balise (mettre : \usepackage[#SPIP2LATEX_CHARSET{#CONFIG{spip2latex/encodage, iso-8859-1}}]{inputenc} )
      • lorsque le code est trop long, le retour à la ligne ne semble pas se faire (du moins dans une liste). Peut être que l’on n’y peut rien ?
      • le code parait écrit plus gros. Est-ce simplement le type de police qui change ?

      La suite au prochain épisode :)

    • Je me demande si dans la page pdf.html, à la place d’un appel à une URL externe (qui ne comprendra pas un éventuel ?var_mode=calcul, il ne faudrait pas tester un :

      [(#FILTRE{spip2latex_pdf_output})]
      [(#INCLURE{fond=latex, env})]

      De la sorte, c’est le filtre (à adapter) qui ferait les post-traitements pour passer à PDF, et on pourrait bénéficier d’un cache.

    • Bon, ça ne va pas avec #FILTRE : il filtre le code PHP généré... mais les inclusions ne sont pas encore dedans. Peut être avec le pipeline affichage_final...

      Déjà, je pense que ajouter : || in_array(_request('var_mode'), array('calcul', 'recalcul')) au moment du test des sources existantes pourrait aider à ce que &var_mode=calcul sur la page pdf le recalcule effectivement.

      if (!file_exists($pdffile) || (filesize($pdffile) == 0) || in_array(_request('var_mode'), array('calcul', 'recalcul'))) {

      Dans cette condition, tu pourrais utiliser la fonction de SPIP ecrire_fichier() au passage : if (ecrire_fichier($texfile, $texte) == FALSE) {...}

    • Bon, alors en vrac :

      • J’ai fait la correction pour DOSSIER_SQUELETTE, mais il faut savoir que j’avais pompé ça du module barre typo, qui vu son grand age me semblait irréprochable. Il y a peut être une suggestion à faire là bas.
      • IMG a été remplacé par img
      • J’ai intégré tes suggestions pour le var_mode=calcul des pdf, et le ecrire_fichier().

      Sur l’idée de faire passer les PDF dans le cache de SPIP. Ca serait mieux, mais je ne suis pas très optimiste. En particulier, il faudra un moyen de purger le PDF lorsque l’article correspondant est calculé.

      Sur la balise #SPIP2LATEX_CHARSET :
      Son argument est censé être optionnel. Sans argument, la balise est doit renvoyer ce qu’on lui a passé avant, ou ce qui a été configuré dans le module CFG, ou à défaut latin-1. L’idée est que latex.html fixe la valeur à ce qu’on trouve via CFG, ou latin-1 à défaut, mais que l’usager qui surcharge latex/preambule.html a toujours la possibilité d’utiliser autre chose. Je ne doute pas que ce besoin se fera sentir sur un site multilingue, dans la mesure où utf-8 en LaTeX est un sport difficile, et où latin-1 est évidemment limité.

      J’ai mis une valeur par défaut pour faire taire le warning PHP

      Et nous voila avec une version 0.9.5

    • Bon... après re réflexions sur cette histoire de .pdf et de cache... je pense vraiment qu’il faut laisser SPIP gérer le cache du fichier, en mettant dans le squelette PDF les entêtes qu’il faut (notamment pour dire que c’est un fichier pdf) ET le code source du PDF généré. Ainsi, on pourrait bénéficier de #CACHE et de ?var_mode=calcul sur ce fichier. C’est peut être quelque chose comme (testé) :

      [(#INCLURE{fond=latex,env}|spip2latex_source_pdf_avec_cache)]

      Et la fonction (rapidement faite, notamment, il n’y a pas là de gestion du nom du fichier...)
      Il faudrait peut être passer objet/id_objet à la fonction le cas échant pour calculer le titre du document. Je n’ai testé qu’avec ma configuration UTF-8 :

      <?php
      function spip2latex_source_pdf_avec_cache($texte) {
      	$filename = "document.pdf";
      
      	$latexdir = sous_repertoire(_DIR_CACHE, 'latex');
      	$tmpdir = sous_repertoire($latexdir, $tag);
      	$tmpdir = sprintf("%s/%s", getcwd(), $tmpdir);
      
      	$id = sha1($texte);
      	$texfile = sprintf("%s%s.tex", $tmpdir, $id);
      	$pdffile = sprintf("%s%s.pdf", $tmpdir, $id);
      	$logfile = sprintf("%s%s.log", $tmpdir, $id);
      	$idxfile = sprintf("%s%s.idx", $tmpdir, $id);
      	$auxfile = sprintf("%s%s.aux", $tmpdir, $id);
      	$outfile = sprintf("%s%s.out", $tmpdir, $id);
      	
      	ecrire_fichier($texfile,
      		# bug/feature de fwrite... il faut utf8_encode dans la fonction pour qu'il comprenne qu'on souhaite de l'utif8 !
      		unicode_to_utf_8(utf_8_to_unicode($texte))
      	);
      	
      	$cmd = sprintf("pdflatex -interaction=batchmode ".
      			 "-output-directory=%s %s",
      			 $tmpdir, $texfile);
      	exec($cmd, $output, $retval);
      	
      	if ($retval) {
      		// gerer l'erreur (avec erreur_squelette ?)
      		var_dump(file_get_contents($logfile));
      	} else {
      		$filesize = filesize($pdffile);
      		$etag = sprintf("\"%s\"", md5($pdffile));
      
      		#supprimer_fichier($pdffile); // no no no
      		supprimer_fichier($idxfile);
      		supprimer_fichier($auxfile);
      		supprimer_fichier($logfile);
      		supprimer_fichier($outfile);
      		supprimer_fichier($texfile);
      	}
      	
      	$headers = array(
      		"Content-Type: application/pdf",
      		"Content-Disposition: attachment; filename=\"$filename\"",
      		"Content-Transfer-Encoding: binary",
      		"Content-Length: ".$filesize,
      		"Etag: ".$etag
      	);
      	
      	foreach ($headers as $n=>$header) {
      		$headers[$n] = "<?php header(\"$header\"); ?>";
      	}
      	
      	return implode('', $headers)."<?php readfile(\"$pdffile\"); ?>";
      }
      ?>

      + retirer le header text/plain sur latex.html, qui contredit celui de pdf.html pour le coup (mais il pourrait peut être rester, je n’ai pas testé).

      De la sorte : la fonction est appelée sur les calculs et calcule dans ce cas systématiquement le PDF. Les risques sont :

      • disparition du fichier PDF (ça n’a pas vraiment lieu d’être et il sera recréé au prochain calcul)
      • comment actualiser lorsque le contenu de l’objet est mis à jour : bien on laisse faire SPIP, qui rend obsolète son cache dès qu’une modification en base est effectuée... (en fait c’est pas un risque, ça marche !)

      PS : je testais avec la version 0.9.4

    • Sur la balise #SPIP2LATEX_CHARSET :
      Son argument est censé être optionnel. Sans argument, la balise est doit renvoyer ce qu’on lui a passé avant, ou ce qui a été configuré dans le module CFG, ou à défaut latin-1.

      Dans ce cas, il y a un problème dans le code, car il n’y a pas de « sinon » d’écrit pour la balise, si on la met vide :

      function balise_SPIP2LATEX_CHARSET($p) {
      	$charset = interprete_argument_balise(1,$p);
      	$p->code = 'spip2latex_charset('.$charset.')';
      	// -> quelque chose d'à peu près comme ça :
      	$p->code = 'spip2latex_charset(sinon('.$charset.', lire_config('spip2latex/charset', 'latin1')))';
      	return $p;
      }
    • La fonction spip2latex_charset() met maintenant une valeur par défaut si on lui passe NULL, du coup ça devrait marcher.

      Je regarde plus tard pour ton autre message, qui constitue une modification un peu plus intrusive.

    • Matthieu : j’ai mis en place ta suggestion avec spip2latex_source_pdf_avec_cache, mais il y a un soucis : le PDF calculé avec pdflatex ne nous sert plus une fois que SPIP a mis le PDF en cache, mais quand est-ce qu’on va l’effacer ?

    • Ah oui, mais non : il ne faut pas le supprimer :p
      Ce que l’on met dans le fichier cache est l’envoi du fichier (readfile()), donc, il faut toujours le fichier.

      Ce qui serait à supprimer par contre, ce sont les vieux fichiers PDF lorsque le sha1 du texte a changé (ie : l’article ou le contenu a été mis à jour). Mais je n’ai pas plus d’idées que la solution que tu emploies déjà je crois ?

      En fait, je pense que lors de la création d’un PDF (donc lors d’un calcul du squelettes pdf.html, dans la fonction _avec_cache() ), il faut regarder la date de modification des contenus (c’est une meta SPIP employée pour la gestion du cache). Si elle a changé, il faut lancer la suppression des PDF, avant de créer celui demandé (et de la même manière avec ?var_mode=recalcul).

    • Je m’étais ajouté également la possibilité, sur la vue d’un article ou d’une rubrique, d’ajouter &format_sortie=pdf pour que ça retourne le pdf. Peut être que cela peut d’intéresser de l’intégrer :

      Plugin.xml

      	<pipeline>
      		<nom>styliser</nom>
      		<inclure>spip2latex.php</inclure>
      	</pipeline>

      Dans spip2latex.php :

      function spip2latex_styliser($flux) {
      	if ($flux['args']['contexte']['format_sortie'] == 'pdf') {
      		if (in_array($flux['args']['fond'], array('article', 'rubrique'))) {
      			$base = find_in_path("pdf." . $flux['args']['ext']);
      			$squelette = substr($base, 0, - strlen("." . $flux['args']['ext']));
      			$flux['data'] = $squelette;
      		}
      	}
      	return $flux;
      }

      PS : j’ai certains pdfs se générant bien (ils sont dans le cache), mais qui ne s’envoient pas correctement depuis le PHP (0 octets reçus). Faut que je comprenne ce qui cloche.

    • J’ai trouvé pourquoi sur certaines pages il ne me l’envoie pas correctement. Enfin j’ai trouvé que le pdf a une erreur dedans, mais est bien créé. Du coup, comme je calculais la taille du fichier qu’en cas de réussite du pdf, il m’inscrivait une taille 0. Bref, en calculant la taille du fichier même en cas d’erreur (pour certaines, ça doit passer), c’est déjà mieux, il me l’envoie.

      Reste l’erreur...
      Ça vient de mon raccourcis [?...#trac] dans les phrases tel que :

      Dans ces cas là, elles sont déclarées (dans SPIP) soit dans le fichier [?ecrire/public/balises.php#trac], soit dans le répertoire [?ecrire/balise/#trac]

      Ma fonction php pour gérer ce glossaire me retourne une URL du style : http://core.spip.org/trac/spip/browser/@file@?rev=spip-2.1 à laquelle il ajoute parfois #L123 où 123 est un numéro de ligne.

      Le code LaTeX généré semble pourtant en tenir compte, mais peut être pas entièrement (?) :

      Dans ces cas là, elles sont déclarées (dans SPIP) soit dans le fichier \href{http://core.spip.org/trac/spip/browser/ecrire/public/balises.php\?rev=spip-2.1}{ecrire/public/balises.php\}\footnote{\url{http://core.spip.org/trac/spip/browser/ecrire/public/balises.php\?rev=spip-2.1}}, soit dans le répertoire \href{http://core.spip.org/trac/spip/browser/ecrire/balise/\?rev=spip-2.1}{ecrire/balise/\}\footnote{\url{http://core.spip.org/trac/spip/browser/ecrire/balise/\?rev=spip-2.1}}

      Dans le log de la génération, on trouve notamment :

      LaTeX Warning: No \author given.
      
      Runaway argument?
      {ecrire/public/balises.php\}\footnote {\url {http://core.spip.org/tra\ETC.
      ! Paragraph ended before \hyper@link@ was complete.
      <to be read again> 
                         \par 
      l.198 
            
      I suspect you've forgotten a `}', causing me to apply this
      control sequence to too much text. How can we recover?
      My plan is to forget the whole thing and hope for the best.

      Personnellement, ça ne me parle pas trop :)

    • Je viens de voir une coquille :
      L. 883 chez moi (mais j’ai ajouté des choses styles spip_log pour débugguer) :

      - if (substr($href, 0, 3) == '@\\#')
      + if (substr($href, 0, 4) == '@\\#')
      	$rep = $titre;
    • @coquille : c’est moi la coquille pour le coup... \ ne faisant qu’un seul caractère... désolé :) c’était bien 0, 3 donc :)

      Pour la correction du glossaire... j’ai appliqué ça (à la vavite), et ça semble fonctionner. Il y a certainement mieux à faire :

      +			$t = str_replace('@\\', '', $t);
      			list($t, $bulle, $hlang) = 
      			    traiter_raccourci_lien_atts($t);
    • Autre bug, ou pas (?) Lorsqu’on fait un copier/coller de texte de cadre de code issu d’un PDF généré, on obtient des espaces entre toutes les lettres. Les appostrophes ne sont pas correctes non plus : elles se sont francisées :

      $ t a b l e _ d e s _ t r a i t e m e n t s [ ’ BALISE ’][] = ’ traitement (% s
      ) ’;
      // remarquer ’ à la place de ' ainsi que l'espace entre chaque lettre.
    • Bon bon bon...
      En ajoutant

      $href = extraire_attribut($ref, 'href');
      + $href = str_replace('#', '@\\#', $href);

      J’arrive à générer cette page sans erreur qui contient un raccourcis [?...#trac123].

      On avance :)
      Je suis content !

    Répondre à ce message

  • 2

    Nouvelle version 0.9.3
    -  Traduire en LaTeX un peu d’HTML : <h1> à <h5>, <b>, <i>
    -  Honorer le marquage pour les glossaires
    -  Utiliser le class="langage" das cadres
    -  Balise SPIP2LATEX_CHARSET pour choisir le jeu de caractère de sortie
    -  Distinction entre code en ligne et en bloc

    Moyennant de surcharger le latex.html et le latex/preambule.tex.html, il est donc maintenant possible de sortir en UTF-8 pour faire du RTL.

    Il y a un soucis avec le code PHP verbatim : dans la version 0.9.2, on obtenait la version LaTeX du corps d’un article avec TEXTE*|spip2latex. Dans ce cas, si je met <?php dans l’article, interdire_scripts() intervient après le filtre spip2latex et me le transforme en &lt;?php. L’entité HTML est affichée dans le PDF à la place du chevron, ce qui n’est pas le but recherché.

    La seule solution que j’ai trouvé, c’est d’utiliser la double étoile : TEXTE**|spip2latex. Le <?php n’est plus modifié par interdire_scripts(), mais le code PHP est exécuté par le serveur, ce qui n’est pas souhaitable non plus. La parade mise en œuvre dans cette version 0.9.3, qui demande une relecture de la part de connaisseurs, consiste à ce que spip2latex remplace <? par <?php echo "<?"; ?>. Est-ce raisonnable ?

    • Je n’ai pas tout suivi pour interdire_scripts...
      Mais c’est une question de sécurité que le chevron soit transformé en entité html. Il n’y a pas à avoir de <?php dans un article en dehors d’une boucle <code> ou <cadre> ! Donc que ce soit échappé est très bien !

      Je suis ennuyé pour voir ce qui a changé entre les 2 versions. Croyez-vous possible de déposer le plugin sur la zone et de le modifier par SVN. J’ai l’impression que ce serait plus simple pour suivre le développement.

    • Merci infiniment de votre temps et de votre fidelité à spip,
      Merci

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom