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

  • 18

    bon... voilà quelque chose d’intéressant.

    Pourrais tu en dire plus sur la façon de personnaliser le PDF généré. Qu’est-ce que mange le transformateur pour faire la décoration ? Ou est-ce que Latex contient des information de décoration ? (je n’y connais rien en latex).

    • Bon, alors sans y connaitre rien en LaTeX, ça va être dur. Note que moi non plus je n’y connais pas grand chose, mais j’ai une co-auteur qui maitrise le sujet, je vais la laisser répondre dans les détails. A titre d’exemple éclairant, je copie/colle juste un bout d’incantation à mettre dans le preambule.tex.html pour que les <poesie> soient mis en page dans un cadre à fond bleu clair.

      \renewenvironment{spiptolatexpoesie}{%
              \definecolor{shadecolor}{rgb}{0.741,0.863,0.945} % bleu clair
              \def\FrameCommand{%
              \setlength{\fboxsep}{2.5ex}%
              \colorbox{shadecolor}}
              \MakeFramed {\advance\hsize-\width \FrameRestore}}%
              {\endMakeFramed}
    • J’ai étudié hier soir un peu le livre Framabook sur LaTeX. Ils parlent de séparation de fond et de forme comme avec HTML / CSS... mais autant pour le fond, Latex semble très clair dans ses possibilités (ce qui m’intéresse est faire un export de Programmer.spip.org en LaTeX puis en PDF, notamment avec l’environnement « book »), autant la mise en forme à l’air extrêmement compliqué (bien plus que CSS en tout cas). Je n’ai pas encore compris comment faire d’ailleurs !

      Je serai curieux d’avoir un aperçu du fichier qui génère ton (très beau) PDF sur le site de ton école.


      Concernant le plugin, j’ai du coup jeté un œil sans l’installer. Quelques fonctions me semblent pouvoir utiliser des codes natifs de SPIP, par exemple : transliterration() pour calculer le nom du fichier PDF comme l’utilise la génération d’URL de SPIP, preg_files() pour retrouver tous les fichiers dans les sources SPIP selon un expression donnée ou encore supprimer_fichier() à la place de unlink(). C’est tout ce que j’ai vu pour le moment.

      J’en dirai peut être plus dans les prochains jours si je prolonge cette piste.

      Une des idées serait d’utiliser TextWheel pour passer du format SPIP au format LaTeX. Ce qui serait certainement plus lisible. TextWheel doit être intégré à SPIP 2.3 par ailleurs.

    • La mise en page en LaTeX, c’est horriblement compliqué. Je laisse ça à ma co-auteur, qui va répondre sur ce point.

      Pour ce qui est de faire du LaTeX depuis SPIP avec TextWheel, je peux faire un petit retour d’expérience.. De ce que j’ai compris, la typo de SPIP n’a pas de grammaire écrite, ce qui interdit de faire une traduction dirigée par la syntaxe. Il faut se contenter de rechercher/remplacer, qui sont assez subtils dans la mesure où LaTeX admet de nombreux caractères spéciaux à échapper ou non selon le contexte, et que en prime certains d’entre eux ont aussi un sens spécial en typo SPIP (les accolades, notamment). C’est ces raisons qui rends le code de SPIP2LaTeX un peu complexe [1].

    • Si je peux me permettre d’intervenir avec ma maigre expérience.

      Pour un projet perso, j’ai déjà fait de l’export SPIP vers Latex à l’aide d’une fonction que j’applique sur #TEXTE**|. Cela gère pour le moment les gras, les italiques et les exposants, qui sont mes seuls besoins. Cela tient en 2 lignes.

      Cet été je suis intéressé par améliorer cela, notamment pour t’aider Marcimat pour livre. Je pense que ce serait vraiment cool, en plus on pourrait ainsi avoir facilement une version à jour de SPIP.net en PDF.

      Pour la mise en forme, ce n’est pas forcément évident, ceci dit j’arrive déjà à faire quelque petite chose (réduction de taille de texte pour un environnement donné, changement des couleurs pour les titres et j’en passe). J’ai même un ami qui produit des cartes de jeux entièrement en LaTex.

      Par ailleurs, je pense que sur le projet pour le livre il faudrait utiliser XeLaTex et non pas LaTex. C’est une variante de LaTex qui fonctionne avec les caractères unicodes. En théorie il est possible de faire cela directement en LaTex (avec un package spécifique), mais de fait, cela ne marche pas très bien (notamment pour les caractères grecs).

    • Pour ce qui est de faire du LaTeX depuis SPIP avec TextWheel, je peux faire un petit retour d’expérience.. De ce que j’ai compris, la typo de SPIP n’a pas de grammaire écrite, ce qui interdit de faire une traduction dirigée par la syntaxe. Il faut se contenter de rechercher/remplacer, qui sont assez subtils dans la mesure où LaTeX admet de nombreux caractères spéciaux à échapper ou non selon le contexte, et que en prime certains d’entre eux ont aussi un sens spécial en typo SPIP (les accolades, notamment). C’est ces raisons qui rends le code de SPIP2LaTeX un peu complexe.

    • Note préliminaire, c’est moi la co-auteur du plugin.

      Petite remarque sur l’exemple que Manu a donné pour la mise en forme de <poesie>, il a oublié de préciser qu’il fallait la ligne suivante dans le préambule [1] du document LaTeX :

      \usepackage{framed}

      Pour ce qui est de la personnalisation du document PDF, il « suffit » d’écrire un fichier de style LaTeX monstyle.sty et d’y faire appel dans le préambule du document avec :

      \usepackage{monstyle}

      Il y a un très grand nombre de packages LaTeX qui permettent d’enjoliver la mise en page par défaut. Quelques pointeurs pour démarrer en LaTeX :
      -  La Faq en français : http://www.grappa.univ-lille3.fr/FAQ-LaTeX/
      -  http://doc.ctrlaltdel.ch/LaTeX/manuel/manuel.pdf
      -  http://tex.loria.fr/general/apprends-latex.pdf
      -  http://lozzone.free.fr/index.php?vlunch=latex
      -  http://www.tuteurs.ens.fr/logiciels/latex/
      -  http://www.lesia.obspm.fr/perso/florence-henry/CoursLatex/courslatex.php

      Pour ce qui est de générer un PDF depuis un site entier, on est en train d’y réfléchir, mais ce n’est pas trivial car il faut une solution qui puisse être utilisée quelle que soit l’arborescence du site. SPIP peut avoir une profondeur infinie de rubriques, alors que LaTeX ne connaît que 7 niveaux de sectionnement (\part \chapter \section \subsection \subsubection \paragraph \subparagraph).

      Par ailleurs, je serais ravie d’offrir mes services en LaTeX pour faire la mise en page de Programmer.spip.org.

    • Bonjour, et merci pour ces renseignements.

      J’avais trouvé hier le site du Grappa effectivement.
      Ce qui m’étonne à première vue dans la lecture de LaTeX, notamment des fichiers .sty, c’est sa grande complexité. Là où un fichier CSS peut se « lire » à haute voix et se comprend à peu près, un fichier .sty fait référence à des fonctions connues qu’on surcharge (ou qu’on déclare), où l’ordre des arguments est important. Par exemple la simple modification des marges des titres (http://www.grappa.univ-lille3.fr/FAQ-LaTeX/6.3.html) ne fait pas référence à un mot clé « marge » (margin en CSS), mais se déclare en suivant l’ordre des arguments entre accolades, ce qui m’est très perturbant. La marge haute étant dans la 3è accolade... si je suis bien.

      Par rapport à Programmer, sa spécificité, si on va par là, c’est l’utilisation de code en ligne, et de blocs de code. Pour l’instant, des tentatives que j’ai fait, la balise <code> fait dans le style latex du plugin un saut de paragraphe (block en CSS) au lieu de rester dans le flux de texte (inline en CSS) lorsqu’il n’y a pas de retour à la ligne dans ce code.

      Vis à vis de la limitation en profondeur de LaTex, je pense que ça doit convenir à la plupart des sites : si l’on veut faire un export du site, il faut alors s’arranger pour remettre à plat ce qui est trop profond si c’est le cas. Dans Programmer, on a : lang / chapitres / rubriques / articles / intertitres au maximum, sachant qu’on exporte un livre par langue. Il y a donc au maximum : 4 rangs de profondeur si je suis bien (5 avec les paragraphes) : chapitre / (parfois rubriques) / articles / intertitres / paragraphes (+ exemples).

      Je serai ravi de votre aide de ce côté là pour la mise en page, si l’on choisit d’exporter en LaTeX, ce qui me semble une excellente chose pour diverses raisons. La première raison étant que notre solution actuelle d’export en PDF repose sur un outil qui n’est pas libre de droit (PrinceXML), reposant sur CSS3. L’outil est réellement extrêmement puissant pourtant (voir les exports PDF de http://programmer.spip.org/Le-livre, gérant un peu les cross-références (mais un peu seulement :p). Évidemment, le coté typographie pourrait être amélioré avec LaTeX, mais je suis déjà très content d’arriver à ce résultat d’export PDF :)

      Matthieu.

    • Pour ce qui est de la balise <code>, j’avais en effet déjà repéré que l’on ne faisait pas la distinction entre le code « en ligne » et le code « en paragraphe ». Je rajoute ça sur le TODO.

      Pour ce qui est de la complexité de LaTeX, je le reconnais. C’est beaucoup plus complexe que du CSS... C’est beaucoup plus riche aussi.

      En tout cas, pour l’export actuel en PDF, le résultat est très chouette. C’est tout automatique ?
      Je devrais être capable de faire une feuille de style qui ressemble.

    • C’est génial :)

      Pour ce qui est de la génération PDF actuelle, ce n’est pas « tout automatique » mais presque. J’ai un squelette SPIP appelé avec ?page=integrale&lang=xx qui crée une page HTML / CSS de l’ensemble du contenu du site dans la langue donnée (je le fais uniquement en local car il faut plusieurs minutes pour le générer lorsque la coloration du code est active :p).

      Des balises distinguent les chapitres, les titres de chapitres, et avec CSS 3 j’indique les sauts de page, les entêtes, les références... Il suffit de donner à manger le fichier HTML (c’est à dire la page ?page=integrale&lang=xx à PrinceXML, et il traduit en pdf.

      Je peux également passer un paramètre &format=a5 ou &format=a5nb qui appelle en plus une CSS pour surchanger certains styles et avoir la page en A5 au lieu d’A4, et Noir&Blanc au lieu de couleur.


      Pour ce qui est de la décoration, que ça ressemble ou non n’est pas très important en soi. Déjà, réussir à exporter en Latex en créant une table des matières, index et références, entête, pied serait déjà extraordinaire :p . Le tout est d’arriver à faire un livre utile tant dans son contenu que dans sa forme : à ce titre, quelque chose que j’ai vu en LateX et que je n’ai pas fait en CSS (je n’ai pas cherché) c’est d’avoir le numéro de chapitre dans un bloc coloré dans la marge pour le retrouver facilement depuis la tranche du livre, comme le fait par exemple le livre sur LaTeX http://www.framabook.org/latex.html . (Ça pourrait être aussi le logo du chapitre)

      Il est aussi intéressant de pouvoir réaliser 2 versions : A4 pour une impression imprimante, A5 pour une impression en livre.

    • Autre question, est-il possible d’avoir un exemple code LaTeX et de fichier .sty pour faire afficher un bout de phrase en rouge par exemple... L’équivalent de :

      Ma phrase <span class='important'>est importante !</span> n'est-ce pas ?

      Avec le CSS

      .important {color:red;}

      Juste histoire que je saisisse la transformation des classes sur HTML en latex...

      Merci tout plein :)

    • Moi je dirais qu’on fait un truc comme ça, mais Florence va encore me dire que j’ai oublié un \usepackage

      \definecolor{rouge}{rgb}{1,0,0} 
      
      Voila du texte \textcolor{rouge}{colorié en rouge} 
    • Bon, je pense avoir trouvé ma réponse... en partie :

      % texte
      Un texte \important{très important} il va de soi :)
      
      % fichier .sty
      \usepackage{color}
      
      \newcommand{\important}[1] {%
      	\textcolor{red}{#1}%
      }
    • Attention, avec l’écriture :

      Voila du texte \textcolor{rouge}{colorié en rouge}

      on ne sépare pas le fond de la forme.

      Or, c’est bien cela que l’on souhaite obtenir : modifier le style « important » sans changer la source du texte. Donc simplement en modifiant le fichier .sty. Enfin, c’est dans l’idéal :)

    • Pour ce qui est du code en coloration syntaxique, il existe le package « listings ». Évidemment ce package ne comprends pas le SPIP :) mais il y a peut être moyen de l’enrichir.

      Ça donne quelque chose comme : <cadre class='php'> à traduire par :

      % preambule
      \usepackage{listings}
      % texte
      \lstset{language=PHP}
      \begin{lstlisting}
      for ($i = 1; $i < 3; $i++) {
      	$x .= ma_belle_fonction($i, 100);
      }
      \end{lstlisting}
    • Finalement, pour revenir aux couleurs, j’ai l’impression que définir un environnement se rapproche plus des <span> ou <div> en CSS. On peut les imbriquer avec \begin et \end, ce qui semble intéressant. Un exemple de code :

      % texte
      % ---------
      Un texte avec \begin{code}[ avant (\begin{variable}\#BALISE\end{variable}) après ]\end{code} qui est propre.
      % style
      % ---------
      % les couleurs predefinies
      \usepackage{color}
      % couleur code 
      % - texte
      \definecolor{code.text}{rgb}{0,0.25,0.75} % bleu cyan
      % - variables
      \definecolor{code.var}{rgb}{0,0,0.75} % bleu
      % environnements
      \newenvironment{code}{\color{code.text}}{}
      \newenvironment{variable}{\color{code.var}}{}

      Reste à trouver comment passer de inline à block et faire des marges, et j’aurais compris le plus gros, j’espère :)

    • Pour le code en ligne, il vaudrait mieux utiliser les fonctionnalités du package listings.

      % préambule
      \usepackage{color}
      \definecolor{code.text}{rgb}{0,0.25,0.75} % bleu cyan
      \definecolor{code.var}{rgb}{0,0,0.75} % bleu
      
      \usepackage{listings}
      \lstdefinestyle{text}{basicstyle=\ttfamily\color{code.text}}
      \lstdefinestyle{var}{basicstyle=\ttfamily\color{code.var}}
      
      % texte 
      Un texte avec \lstinline[style=text]{[ avant (#BALISE) après ]} qui est propre \lstinline[style=var]{(#BALISE)}.

      L’avantage est que le code est plus lisible.
      L’inconvénient est qu’on ne peut pas imbriquer les \lstinline. Mais le salut sera sans doute dans la rédaction du style SPIP pour listings. Je vais y plancher.

    • Dans SPIP, la balise <code> ne passe pas, à ma connaissance, dans le plugin de coloration syntaxique par défaut, et cette balise n’a pas d’attribut pour désigner le type de code (cela dit, elle pourrait très bien en avoir un et l’utiliser). En général, nous utilisons <code> pour du code à même le texte, et <cadre> pour des blocs de code. Pour la distinction bloc / inline, gérer <code> tout le temps inline et <cadre> tout de temps bloc devrait convenir.

      J’ai regardé un peu les sources de listings, il semble qu’il s’appuie essentiellement sur une liste de vocabulaire connu, et non sur un parseur, par exemple à base d’expressions régulières, mais je me trompe peut être.

      [ avant (#TRUC_MUCHE) après ]

      risque donc d’être difficile à colorer car on ne peut pas présupposer le nom « truc_muche ».

      Matthieu.

    • pour un bouquin que j’écrit, j’utilise le minted package http://www.ctan.org/tex-archive/macros/latex/contrib/minted/ qui fait de la coloration syntaxique en ligne ou en bloc.

      Il est écrit en python, donc ca devrait pouvoir ce faire de créer une coloration syntaxique spécifique à SPIP.

    Répondre à ce message

  • 4

    Je fais la liste des points que je rencontre comme bloquants (je n’ai pas cherché à corriger, je liste juste :) ) :

    • ligature « œ » (1 seul caractère) non reconnu : tout ce qui est après n’est pas affiché dans le PDF
    • <code> comme déjà signalé ne reste pas en ligne, met une bordure tout autour, mais n’a pas de texte à l’intérieur (le cadre est vide !)
    • les glossaires [?lien] ne sont pas pris en compte et sont affichés : « Toute l’interface publique (dans le répertoire [?squelettes-dist#trac]) »
    • Les <cadre> semblent aussi disparaître en partie (avec le plugin coloration code, le cadre
      <cadre class="spip">
      <B_art>
        <ul>
          <BOUCLE_art(ARTICLES){!par date}{0,5}>
            <li><a href="#URL_ARTICLE">#TITRE</a></li>
          </BOUCLE_art>
        </ul>
      </B_art>
      </ cadre>

      affiche :
      Liste des 5 derniers articles :

      #TITRE

      Comme si tout le XML disparaissait.

    • lorsqu’un modèle utilisé n’est pas trouvé avec latex_nom_du_modele... faire afficher un message plus voyant ? ou tenter sans le prefix latex_ d’afficher le contenu en texte brut ? si c’est possible ? . Là, j’ai un très discret « latex synthese 57 » qui apparait :)
    • pour la ligature, essaie de compiler non pas avec latex mais avec xelatex.

      envoi moi un fichier exemple au cas où ...

    • Alors... si je compile chez moi via Textmaker, je n’ai pas d’erreur en UTF8, mais il râle en Latin1, or dans le plugin, c’est bien une déclaration latin 1 qui est utilisée, il y a peut être un rapport. Source :

      \documentclass[10pt,a4paper]{book}
      \usepackage[utf8x]{inputenc}
      %\usepackage[latin1]{inputenc}
      \usepackage[francais]{babel}
      \author{MM}
      \title{Programmer}
      \begin{document}
      Ok avec des «guillemets», des suspensions… et un œuf !
      \end{document}
    • Pour les codes et cadre...

      voici ce que j’ai fait et modifié, il faut notamment que <cadre class='php'> puisse fonctionner, or le plugin ne prend en compte que <cadre> comme syntaxe. Idéalement, il faudrait récurérer la valeur « php » mais je ne l’ai pas fait dans cette correction :

      Dans spip2latex.php, autour de la ligne 843, changer la regexp et inverser les échappements entre code et cadre :

      <?php //...
      	foreach ($verbatim as $v => $lv) {
      		$regex = sprintf('|<%s(?:\s[^>]*)?>(.*)?</%s>|UmsS', $v, $v);
      		if (preg_match_all($regex, $t, $matches, PREG_SET_ORDER)) {
      			foreach ($matches as $m) {
      				switch($v) {
      				case 'code':
      					$r = sprintf(
      					    "\n\\begin{spiptolatexcode}\n".
      					    "%s\n\\end{spiptolatexcode}\n", 
      					    spip2latex_escape_latex0($m[1]));
      					break;
      				case 'cadre':	/* FALLTHROUGH */
      				case 'frame':
      					$r = sprintf(
      					    "\n\\begin{spiptolatexcadre}\n".
      					    "%s\n\\end{spiptolatexcadre}\n", 
      					    $m[1]);
      					break;
      // ...
      }}}}

      Dans le fichier de préambule, adapter code (simple couleur) et cadre (avec listings), par exemple :

      % commenter ou supprimer
      %\newenvironment{spiptolatexcadre}{}{}
      % modifier :
      % Code
      %
      % couleur code 
      % - texte
      \usepackage{color}
      \definecolor{code.border}{rgb}{0.7,0.7,0.7} % gris
      \definecolor{code.text}{rgb}{0.1,0.1,0.5} % bleu gris
      
      \usepackage{listings}
      \lstset{%
      	extendedchars=true,
      	breaklines=true,
      	basicstyle=\ttfamily
      }
      \lstnewenvironment{spiptolatexcadre}{%
      	\lstset{%
      		frame=single,
      		framesep=1ex,
      		rulecolor=\color{code.border},
      		xleftmargin=1ex,
      		xrightmargin=1ex
      	}
      }{}
      
      %\lstnewenvironment{spiptolatexcode}{}{}
      \newenvironment{spiptolatexcode}{%
      	\color{code.text}
      }{}

      Ce n’est qu’un exemple, mais au moins j’ai les codes et cadre qui s’affichent. C’est loin d’être parfait niveau présentation tout de même !

    • Corrobori

      ligature « œ » (1 seul caractère) non reconnu : tout ce qui est après n’est pas affiché dans le PDF

      Je tente une piste : il faut prendre en compte 2 choses dans LaTEX l’encodage du document au moment de sa création iso latin1, mac roman, utf8 … et les packages utilisés. Ainsi dans un document au format mac roman rien ne dit que

      \usepackage[utf8]{inputenc}

      ne donne les effets attendus.

      Il doit falloir garder la cohérence entre format et package.

      En espérant aider, je vous suis de près sur ce plugin.

    Répondre à ce message

  • 1

    Sur les différents points soulevés, je souhaite lancer un appel à commentaire :

    Sortir en UTF-8
    Certains usagers auront besoin de faire du code LaTeX en UTF-8, par exemple pour les langages RTL. Néanmoins la possibilité de sortir en ISO-8859-1 est importante, car si j’ai bien compris, certains paquetages LaTeX ne marchent bien qu’en ISO-8859-1.

    Avec cette double exigence, il semble souhaitable que le choix du jeu de caractère de sortie soit configurable. On pourrait imaginer de passer par CFG pour cela, mais c’est peu intéressant, car on doit aussi toucher à latex/preambule.tex.html pour préciser la langue et le jeu de caractère. Si on doit modifier des squelettes, cela plaide pour que le réglage du jeu de caractère de sortie se fasse dans les squelettes.

    J’ai expérimenté l’ajout d’un argument optionnel au filtre spip2latex() pour indiquer le jeu de caractère de sortie. L’inconvénient est qu’il faut le préciser à chaque utilisation du filtre dans le squelette. Est-ce que quelqu’un a une meilleure idée ?

    Sur les cadres PHP
    Il semble qu’une bonne approche serait que l’environnement spiptolatexcadre prenne un argument optionnel où on mettra une éventuelle classe, qu’on aura récupéré depuis l’attribut class. Ensuite, dans le .sty, on peut utiliser les options déjà toutes faites de LaTeX pour rendre tel ou tel langage.

    Tant qu’on est là, on peut essayer de s’assurer qu’on ne rate rien d’autre autour de ces modèles. Question: : est-ce qu’il y a une liste exhaustive des attributs et de leurs valeurs possibles qu’on utilise dans les modèles cadre, code, poesie et quote,

    Sur les marquages en ligne ou en bloc
    Actuellement on traite pareil un <code> en ligne ou en bloc, il va falloir qu’on change ça. La distinction semble simplement la présence d’un retour de chariot après le <code>

    • Pour UTF8 et les langues je vois 2 solutions pour l’instant.

      • La première est de fournir un langue.sty appelé dans le preambule, il suffirait de ne surcharger que ce fichier là. Par exemple avec [(#INCLURE{fond=latex/langue.sty})]
      • la seconde consiste à utiliser CFG (et/ou bonux) ou des define() et d’utiliser dans le préambule (qui est un squelette SPIP) des appels à ces valeurs tel que #CONFIG{latex/langue}. Il est aussi possible de proposer #CONFIG{latex/vos_styles} avec un textarea dans un formulaire de configuration que les gens peuvent remplir au besoin (mais #INCLURE{fond=latex/mes_styles} est tout aussi bien en en mettant un vide par défaut)

    Répondre à ce message

  • Sur les différents points soulevés, je souhaite lancer un appel à commentaire :

    Sortir en UTF-8
    Certains usagers auront besoin de faire du code LaTeX en UTF-8, par exemple pour les langages RTL. Néanmoins la possibilité de sortir en ISO-8859-1 est importante, car si j’ai bien compris, certains paquetages LaTeX ne marchent bien qu’en ISO-8859-1.

    Avec cette double exigence, il semble souhaitable que le choix du jeu de caractère de sortie soit configurable. On pourrait imaginer de passer par CFG pour cela, mais c’est peu intéressant, car on doit aussi toucher à latex/preambule.tex.html pour préciser la langue et le jeu de caractère. Si on doit modifier des squelettes, cela plaide pour que le réglage du jeu de caractère de sortie se fasse dans les squelettes.

    J’ai expérimenté l’ajout d’un argument optionnel au filtre spip2latex() pour indiquer le jeu de caractère de sortie. L’inconvénient est qu’il faut le préciser à chaque utilisation du filtre dans le squelette. Est-ce que quelqu’un a une meilleure idée ?

    Sur les cadres PHP
    Il semble qu’une bonne approche serait que l’environnement spiptolatexcadre prenne un argument optionnel où on mettra une éventuelle classe, qu’on aura récupéré depuis l’attribut class. Ensuite, dans le .sty, on peut utiliser les options déjà toutes faites de LaTeX pour rendre tel ou tel langage.

    Tant qu’on est là, on peut essayer de s’assurer qu’on ne rate rien d’autre autour de ces modèles. Question: : est-ce qu’il y a une liste exhaustive des attributs et de leurs valeurs possibles qu’on utilise dans les modèles cadre, code, poesie et quote,

    Sur les marquages en ligne ou en bloc
    Actuellement on traite pareil un en ligne ou en bloc, il va falloir qu’on change ça. La distinction semble simplement la présence d’un retour de chariot après le

    Répondre à ce message

  • 3

    Bonjour, merci pour le plugin, je veux savoir si le plugin peut generer des pdfs en langue RTL, comme l’arabe parceque j’ai vraiment besoin de ca, dans mon site et ca sera la meilleur nouvelle pour moi de cette année, spipdf ne le fait pas corectement.

    Merci et bon courage

    • Resalut, pouvez vous m’aider, ou me proposer une solution.
      Merci

    • Oui, oui, c’est juste qu’on planche un peu avant de répondre pour ne pas dire une bêtise. Patience !

    • salut
      mes remerciements pour le travail que vous realisez, je serais patient
      Merci

    Répondre à ce message

  • Je viens de faire une version 0.9.2, qui contourne le warning sur parse_url() et l’erreur sur file_put_contents(), qui surviennent sur les anciennes versions de PHP.

    Suivant le conseil de Matthieu Marcillaud, j’ai aussi adopté translitteration() et supprimer_fichier(). Par contre je ne vois pas où je pourrais utiliser preg_files() pour simplifier les sources.

    Répondre à ce message

  • 1

    Bonjour, merci pour le plugin, j’ai eu une erreur de type

    Warning : parse_url() expects exactly 1 parameter, 2 given in plugins/spip2latex-0.9.1/spip2latex-0.9.1/spip2latex.php on line 951

    Fatal error : Call to undefined function : file_put_contents() in plugins/spip2latex-0.9.1/spip2latex-0.9.1/spip2latex.php on line 1011

    Je ne sais pas d’ou viens peut etre de l’url , en barre d’adresse j’ai l url suivante :
    /spip.php ?page=pdf&id_article=5
    et en plus je suis sur hebergement mutualisé, OVH, (j’ai pas de serveur) et je ne sais pas comment :
    ajouter la commande pdflatex dans le PATH . (dans quelle fichier si c’est possible).

    Pouvez vous m’aidez,

    Merci

    • Ces deux erreurs sont dues à une version de PHP un peu plus vieille que celle sur laquelle le plugin a été développé. Je vais faire une nouvelle version y remédiant rapidement.

      Pour ce qui est de l’hébergement mutualisé, je doute que l’hébergeur vous propose d’utiliser pdflatex, mais vous pouvez toujours leur demander.

    Répondre à ce message

  • Au fait, comme ça n’est pas forcément évident, SPIP2LaTeX traduit toute la typo SPIP : gras, italique, exposant, indice, barré, cadres, citation, code, poésie, alignements, images, listes, tableaux, liens, documents joints, modèles... (je dos en oublier).

    Ce qui manque : passage en UTF-8, export de tout le site, que faire des formulaires, des objets embarqués, de l’HTML...

    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