spiPDF : générer des contenus sur mesure en PDF

Publié le : 16 février 2011 – Dernière modification le 14 novembre 2023 – par Yves Tannier – 265 commentaires

1
2
3
4
5
75 votes

Le plugin spiPDF génère des fichiers au format PDF d’article ou de tout autre élément SPIP, simplement à partir d’un squelette construit au format HTML 4 et facile à modifier.

Avertissement de sécurité

Ce plugin a fait l’objet d’une faille de sécurité en mars 2017, il est important d’avoir son site SPIP et le plugin à jour pour continuer à utiliser ce plugin en toute sécurité

Présentation

Le plugin génère des fichiers PDF à partir d’un squelette écrit au format HTML 4.
Il vous permet donc de créer un PDF réellement sur mesure sans d’autre compétence que de connaître le HTML 4 et CSS.

Que ce soit un squelette pour vos articles, vos rubriques, votre plan de site ou d’autres éléments plus spécifiques, spiPDF génère le contenu en PDF.

Plusieurs librairies, plusieurs possibilités

Le plugin [1] se base - au choix de l’utilisateur - sur plusieurs classes de génération de PDF à partir de HTML :

Par défaut, le plugin utilise mPDF. Vous verrez plus bas dans cet article comment utilisez un autre librairie à la place.

Chacune des classes à ses avantages et ses inconvénients. On notera par exemple que mPDF gére le positionnement flottant (“float”) des éléments ce qui est indéniablement un plus pour de la génération d’article contenant des images.

N’hésitez pas à donner votre avis et vos expériences sur les différentes librairies dans les commentaires de l’article.

Pré-requis

A partir de la version v2.0.2 (compatible SPIP 4)
il est nécessaire d’avoir PHP 8.0 ou plus (pour la compatibilité avec les librairies embarquées)

Pour les versions v1.2.0 et précédentes, le plugin requiert :

  • PHP 5
  • d’installer manuellement dans le répertoire /lib/ une librairie (voir chapitre précédent)

Téléchargement et installation des librairies requises

A partir de la version v2.0.2 (compatible SPIP 4)
Il n’est plus nécessaire d’intégrer les librairies d’une facon externe, elles sont intégrées dans le répertoire vendor du plugin

Dans les anciennes versions
Vous devez les télécharger sur leurs sites respectifs et les décompresser dans un répertoire lib/ à la racine de votre site ou dans un répertoire lib/ dans le répertoire du plugin :

Les dossiers doivent se nommer exactement respectivement mpdf, html2pdf ou dompdf (sans majuscules).

Rendu obtenu avec les différentes librairies

Après un test simple de chacune des librairies, voici les résultats que j’ai obtenu :

  • mPDF version 6.0 du 01/03/2015 : bon rendu général
  • HTML2PDF version 4.03 du 27/05/2011 : rendu du texte correct, problème avec certains positionnements d’images
  • domPDF version 0.6.0 beta2 de 02/2011 : problème d’encodage des caractères

Utilisation

Une étape supplémentaire suffit pour commencer à utiliser le plugin.

Ajoutez un lien hypertexte vers le squelette du plugin, typiquement dans votre squelette article.html. Voici à quoi doit ressembler ce lien pour un article :

[<a href="[(#URL_PAGE{spipdf}
	|parametre_url{spipdf,spipdf_article}
	|parametre_url{id_article,#ID_ARTICLE}
	|parametre_url{nom_fichier,article_#ID_ARTICLE})]">
télécharger l'article au format PDF</a>]

Mise en page personnalisée

C’est tout l’intérêt du plugin : permettre une mise en page personnalisée sans connaître le PHP.

Pour obtenir un PDF sur mesure, vous pouvez :

  • soit modifier le squelette qui se trouve dans le répertoire du plugin : spipdf_article.html
  • soir créer votre propre squelette et modifier la balise #URL_PAGE pour qu’elle appelle bien votre squelette à la place de spipdf_article (remplacer spipdf_article par le nom de votre squelette)

Par exemple, vous avez dans votre répertoire squelette, un squelette plan_site_pdf.html que vous souhaitez utiliser pour générer une sortie PDF de votre plan de site.

Il vous suffira d’appeler ce squelette/PDF de la façon suivante :

[<a href="[(#URL_PAGE{spipdf}
	|parametre_url{spipdf,plan_site_pdf}
	|parametre_url{nom_fichier,plan_site_pdf})]">
télécharger le plan de site au format PDF</a>]

Ce qui donnera l’URL : http://monsite.tld/spip.php?page=spipdf&spipdf=plan_site_pdf.html

Liens vers des articles SPIP dans le PDF

Si vous utilisez des liens internes du type [->art2] dans vos articles,
il est nécessaire d’utiliser le filtre abs_url sur les balises
DESCRIPTIF, CHAPO, TEXTE, PS et NOTES pour que les liens dans votre PDF pointent bien sur votre site.

Nom de fichier personnalisé

Par défaut, les fichiers PDF se nommeront document.pdf.

Si vous souhaitez préciser un nom particulier pour votre fichier, vous devrez préciser, comme dans les exemples ci-dessus, le paramètre nom_fichier dans la balise #URL_PAGE.

Choix de la librairie de génération

Pour sélectionner l’une ou l’autre des librairies supportées, vous devez changer la valeur de l’attribut lib_pdf dans la balise du squelette spipdf_article.html ou de votre squelette personnalisé/

Les valeurs possibles sont mpdf / html2pdf / dompdf

Vous pouvez utiliser une librairie différente par type de squelette.

Format, orientation des pages et autres subtilités

Chaque librairies autorisent la mise en page directement depuis le squelette HTML mais pas de la même façon.

Pour plus de simplicité, le format (A4, A5, Letter...) est cependant gérés par le plugin depuis cette balise page pour toutes les librairies.

Pour le reste (marge, bordure, header, footer...) chaque outils à son propre fonctionnement mais tout ceci sans toucher au code du plugin.

mPDF

La librairie utilise le sélecteur CSS @page. Ceci est également explicité dans la documentation (en anglais) de la bibliothèque.

HTML2PDF

La librairie utilise les paramètres précisés via la balise (voir le squelette spipdf_article.html pour l’exemple)

Vous trouverez plus d’informations sur le wiki de la librairie et plus particulièrement sur la section concernant la fameuse balise page.

dompdf

Le support étant expérimental, je n’ai pas plus d’informations pour l’instant à fournir. A voir sur le site de cette librairie.

Contraintes et bugs connus

Certaines balises HTML peuvent ne pas être gérées par le plugin

C’est notamment le cas de balises qui ne sont pas gérées par la librairie que vous avez choisi d’utiliser. Dans ce cas, vous devriez obtenir une erreur à la génération du PDF ou un affichage dégradé. Dans cette situation, 2 solutions :

  • le HTML qui pose problème est dans votre squelette ? et bien... trouvez autre chose en attendant mieux (mais signalez-le quand même dans les commentaires)
  • le HTML est généré par SPIP ? Signalez-le dans les commentaires pour une mise à jour du plugin

Certaines balises CSS ne sont pas gérées par le plugin

Bien entendu, dans ce cas, l’affichage au format PDF sera différent de l’affichage au format HTML. On notera par exemple que le positionnement float est géré en partie par mPDF et pas du tout par HTML2PDF.

Vous devrez palier à certaines contraintes de positionnement en utilisant des tableaux imbriqués (snif !)

Encore une fois, toutes ces contraintes sont explicitées sur les site et les forums des librairies respectives.

Changer l’encodage utilisé pour la génération de PDF

Le plugin génère les PDF en UTF-8. Certaines personnes ont rencontré des problèmes de génération des contenus dans cet encodage.

Pour changer ce comportement, et utiliser ISO-8859-15, vous devez changer la constante suivante dans votre fichier d’options :

define('SPIPDF_CHARSET', 'ISO-8859-15');

Aide au développement

Pour pré-visualiser la page au lieu de générer le PDF, vous pouvez ajouter le paramètre debug_spipdf à l’URL
Par exemple : spip.php?page=spipdf&spipdf=spipdf_article&id_article=1249&nom_fichier=article-1249&debug_spipdf

Notes

[1] Depuis la version 0.2.0

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

96 discussions

  • 1
    Benoît Labourdette

    Savez-vous où se trouve le cache des fichiers PDF générés ? Car, après avoir fait des modifications dans mon article, quand je génère le PDF, il sort la version ancienne de l’article en PDF. Je pourrais vider le cache du site entier, mais j’aimerais pouvoir vider uniquement le cache des fichiers PDF. Car vider le cache de l’article ne suffit pas.

    J’utilise aussi les plugins Cache Cool et Memoization, c’est peut-être plutôt de ce côté là qu’il faut aller voir. Mais j’ai cherché sur le serveur où diable pourraient être ces fichiers PDF en cache, et je ne les trouve pas. Merci pour votre aide !

    Répondre à ce message

  • Jérôme

    Bonjour,
    merci pour ce super plugin. J’ai cependant un petit souci : lors de la création du pdf, les styles de mon fichier perso.css ne sont pour la plupart pas appliqués, et je n’arrive pas à comprendre pourquoi.

    Je précise que je n’ai apporté aucune modification aux fichiers du plugin ni au fichier de mon squelette (Escal).

    Quelqu’un peut-il m’aider ? merci !

    Répondre à ce message

  • ygornet

    Bonjour

    Avec SpiPDF v2.0.2 et spip v426, je souhaite utiliser la librairie html2pdf .
    PHP Version 8.2 et MySQL v8.0 via l’extension PHP MySQLi.
    J’installe la librairie à la racine du site à l’aide de composer require spipu/html2pdf.

    Et ça me répond :
    « Echec generation PDF avec html2pdf : Impossible de trouver le répertoire lib/html2pdf/ de la librairie HTML2Pdf »
    Effectivement il n’y a rien dans lib/ ...

    D’où ma question : comment donc installer cette librairie pour le plugin puisse s’en servir ?

    Merci d’avance de votre réponse

    Répondre à ce message

  • 1
    erational

    Les liens vers les ancres internes ne sont pas supportés.

    Cela peut être gênant notamment avec des plugins comme sommaire automatique.

    Pour que cela fonctionne, il faut « corriger » le HTML avec des filtres maisons (voir spipdf/inc/spipdf_nettoyer_html.php#193)

    <a id="alice"></a>  doit s'écrire <a name="alice"></a>
<h2 class="h2" id="bob">... doit s'écrire  <h2 class="h2"><a name="bob"></a>...
    • Helem

      Bonjour

      Ça m’intéresserait aussi de pouvoir rendre actifs les liens générés par « Sommaire automatique »...

      Par ailleurs, dans les pdf générés, le « nettoyage » des appels de notes présent dans « spipdf_nettoyer_html » ne fonctionne pas par chez moi : l’appel de note reste inactif.

      Merci

    Répondre à ce message

  • Denis

    J’essaie ce plugin en spip 4.2 et de passer en export sous différentes tailles.

    Je modifie donc spipdf_article.html par exemple en remplaçant format=« A4 » par format=« A3 » mais je reste en A4.

    Une idée de comment tester des exports en différents formats ? Merci !

    Répondre à ce message

  • RadisNoir

    Si jamais, pour ceux qui ont une erreur à l’ouverture des PDF générés avec la librairie mpdf dans Adobe Acrobat. J’ai trouvé une solution dans un forum (https://stackoverflow.com/questions/72739829/mpdf-file-only-works-in-browser-not-in-adobe-acrobat-format-error).

    Dans le fichier mpdf.php il suffit de changer la ligne :

    $errorlevel=error_reporting($errorlevel & ~E_NOTICE);

    par

    $errorlevel=error_reporting(E_ERROR | E_PARSE);

    Répondre à ce message

  • 3
    Julius-G

    Bonjour à tous, Merci pour ce plugin.
    J’utilise la librairie par défaut MPDF.
    Ce que j’ai besoin de mettre en place c’est un sommaire / index reconnu par un lecteur PDF.

    Sur le site de la librairie j’ai :
    https://mpdf.github.io/reference/mpdf-functions/insertindex.html

    Par contre je ne comprends pas comment ajouter ce paramétrage dans le plugin / dans mon article.

    Quelqu’un aurait-il une idée ?

    Merci,
    JG.

    • Peetdu

      Idée (non testée) : surcharger le squelettes spipdf_article.html avec la balise #SOMMAIRE du plugin Sommaire automatique ?

    • Julius-G

      Bonjour Peetdu,

      Merci pour ta proposition.
      En fait ce n’est pas un sommaire que je souhaite en début de PDF, mais c’est bien le volet a gauche qui est généré sur un PDF. Et pour cela il faut des options spécifiques lors de la constitution du PDF.

      Et du coup, comment passer ces fameux paramètre de la librairie MPDF pour générer cet index reconnu par les readers PDF....

    • Benoît Labourdette

      Désolé pour la question de débutant : où télécharges tu la librairie mpdf ?
      Sur cette page (https://packagist.org/packages/mpdf/mpdf#v8.1.1) je ne trouves pas où on le télécharge.
      Et dans quel dossier tu l’installes ? (dans www/lib, je pense, mais quel nom de dossier mets-tu ? )
      Merci !!

    Répondre à ce message

  • 2
    Benoît Labourdette

    Bonjour,
    Le plugin fonctionnait parfaitement avec la librairie mpdf et PHP 7.4.
    Je suis passé à PHP 8.1.
    J’ai mis à jour la dernière version de mpdf, qui fonctionne avec PHP 8.1, mais pas avec le plugin. J’ai aussi essayé avec la librairie dompdf, mais idem, la dernière version ne fonctionne pas avec le plugin. Et j’ai aussi essayé avec la dernière version de HTML2PDF, mais idem, le plugin ne veut pas fonctionner, il dit :
    Erreur d’exécution plugins/auto/spipdf/v1.2.6/spipdf.html
    Est-ce que quelqu’un a réussi à faire fonctionner ce plugin avec PHP 8.1 ?
    Merci !!

    Répondre à ce message

  • 1
    cy_altern

    Compatibilité SPIP 3.2 + PHP 7.0.27 + librairie mpdf :
    Sur un SPIP 3.2 en PHP 7.0, après pas mal de tâtonnements avec la lib mpdf, il semblerait que seule la version 6.1.0 du 26/04/2016 fonctionne sans erreur...
    Pour la récupérer :
    -  soit faire générer le zip avec le bouton vert « clone or download » de la page de github de cette version : https://github.com/mpdf/mpdf/tree/6.1
    -  soit, si vous avez la possibilité d’utiliser git sur la machine qui vous héberge, clonez le repo complet puis activez la version 6.1, ce qui donne en ligne de commande :

    cd lib/
git clone https://github.com/mpdf/mpdf.git mpdf
cd mpdf
git  checkout 6.1

    (pour vérification de la version active, un

    git branch -a

    devrait vous permettre de constater que c’est bien la branche 6.1 qui est active)

    Note importante : le sous-dossier mpdf/ttfontdata doit être accessible en écriture pour apache

    Répondre à ce message

  • 2
    katmandou

    Bonjour,
    Je suis passé à spip 3.2 et php 7.1.3, du coup j’ai plein d’erreurs !
    Il est indiqué que ce plugin fonctionne avec php 5, mais dans les commentaires certains l’utilisent avec php 7, que faire pour cela ?
    Merci de votre aide,
    Chris.

    • Julien

      A première vue ce n’est pas le plugin qui est en cause, mais mPDF.
      En php 7.1, il faut sans doute remettre une lib à jour, mais maintenant c’est via composer.
      Et est-ce que SPIDF va bien trouver la lib si install via composer ? A tester...

    • Julien

      Après avoir installer mPDF 7.0 via composer, SPIPDF ne marche toujours pas, car il cherche une librairie dans /lib... qui n’existe pas via composer !
      Il faudrait adapter SPIPDF à mPDF 7.0...

    Répondre à ce message

  • 1
    Vince

    Bonjour,

    J’ai un souci avec les images.. Elles ne s’affichent pas.

    Php 7.1, Spip 3.2.3, Spipdf 1.2.4, mpdf 6.1

    J’ai essayé avec le squelette fourni avec le plugin, ou avec un squelette perso, même résultat.
    Les images s’affichent sur la version debug html (debug_spidf). Par contre, le PDF correspondant affiche des croix rouges à la place des images.

    J’ai changé la config pour afficher les erreurs :
    $this->showImageErrors = true ;

    et dans le log apache j’ai donc
    [Thu Feb 28 13:05:39.958471 2019] [php7:error] [pid 19965] PHP Fatal error : Uncaught MpdfException : IMAGE Error (http://exemple.fr/local/cache-vignettes/L200xH113/arton526-9e728.jpg?1551357192) : Could not find image file in /home/vinceweb/sites/exemple/web/lib/mpdf/mpdf.php:11752..................

    Url absolue ou relative, ça n’a pas l’air de solutionner ...

    Quelqu’un à ce problème ? Et une solution, tant qu’à faire ?

    Merci d’avance !

    • Vince

      Je suis passé sur DomPdf 0.7, et mes images s’affichent

    Répondre à ce message

  • 2
    Bredt

    Merci pour ce super plugin.
    Un petit truc pour les utilisateurs :
    Si vous voulez utiliser spiPDF avec Dompdf > 0.6.2, il faut remplacer la ligne 358 de spipdf_fonctions.php

    require_once $dir_librairie_pdf . 'dompdf_config.inc.php';

    par

    require_once $dir_librairie_pdf.'lib/html5lib/Parser.php';
require_once $dir_librairie_pdf.'lib/php-font-lib/src/FontLib/Autoloader.php';
require_once $dir_librairie_pdf.'lib/php-svg-lib/src/autoload.php';
require_once $dir_librairie_pdf.'src/Autoloader.php';
Dompdf\Autoloader::register();
use Dompdf\Dompdf;

    En effet à partir de la version 0.7.0, le fichier dompdf_config.inc.php n’est plus utilisé.

    La dernière version de Dompdf peut se trouver là :
    https://github.com/dompdf/dompdf/re...

    • Bredt

      On repends et on recommence, et en plus cette fois ça marche :
      ligne 358 par

      require_once $dir_librairie_pdf.'autoload.inc.php';

      et ligne 360 par

      $dompdf = new Dompdf\Dompdf();

      On peut en passant changer les fonctions obsolètes (lignes 361 et 362) :

      • load_html ⇒ loadHtml
      • set_paper ⇒ setPaper
    • Vince

      Merci, ça à l’air de mieux marcher que mpdf

    Répondre à ce message

  • 1
    AbsurdePhoton

    La création des PDF peut prendre un certain temps : les utilisateurs de sites web étant de plus en plus pressés, il serait peut-être bien de proposer une option pour pouvoir afficher un indicateur d’attente pendant que le fichier est généré ?

    Je me demande si c’est possible de faire ça dans le code PhP, ou en CSS.

    • Chourak

      Bonjour,

      J’avoue que je suis pleinement dans ce cas de besoin de montrer le fait que le pdf est entrain de se générer, j’essaie de trouver une solution à mon niveau mais je coince un peu pour le moment.

    Répondre à ce message

  • d.lechenne

    Bonjour

    Comment inclure des polices de caractères personnalisées dans le .pdf ?

    Répondre à ce message

  • 4
    Peetdu

    Pour info : le Bloc « Compatibilité » de cette page ne mentionne que les versions 2.0 et 2.1 de SPIP. Or ce plugin semble être compatible avec SPIP 3.x.

    Quid ?

    Répondre à ce message

  • 6
    AbsurdePhoton

    Hello,

    j’ai trouvé un autre bug sur la version 1.03. Plus loin dans les commentaires, quelqu’un se plaignait d’avoir des problèmes sur les images centrées imgxx|center, et j’ai eu le même problème, qui semblait un peu aléatoire mais seules les images centrées étaient touchées, pas les docxx|center.

    Je l’ai résolu comme ceci :
    * dans le fichier « spipdf_fonctions.php », dans la fonction « spipdf_nettoyer_html »
    * inverser les deux premières instructions suivant les commentaires : « supprimer les spans autour des images et récupérer le placement » et « supprimer les spans autour des images »

    Je pense que mettre le nettoyage des images centrées (donc sans placement « left » ou « right ») permet de ne plus couper à tort du code HTML dans certains cas...

    • Maïeul

      merci, c’est corrigé dans la version 1.0.4 (je vous fais confiance, et n’ai pas vérifier moi même le résultat) https://zone.spip.org/trac/spip-zone/changeset/101517

    • AbsurdePhoton

      Moi j’ai bien vérifié, je n’ai plus de bug, ça marche nickel sur mon site www.absurdephoton.fr (utiliser le lien PDF qui n’apparaît que dans les articles).
      Petite précision j’utilise la version mpdf v6.0 sans aucun autre problème, mais pas la 6.1 si quelqu’un a un retour d’expérience ?
      Par contre la version 7 change radicalement... le plugin spiPDF n’est donc valable que jusqu’à la version 6.x.

    • Pi r

      hello, étrange, si tu supprimes les spans d’emblée, comment récupérer le placement float après ? tes float fonctionnent ?

    • AbsurdePhoton

      Les float n’ont jamais vraiment fonctionné avec mpdf.

    • Pi r

      bonjour, c’est un problème de remplacement des tags html, le float fonctionne en dehors du texte, [(#LOGO_ARTICLE|image_reduire{250}|right)] qui donne <img src="..." alt="" class="spip_documents_right" onmouseover="" onmouseout="" width="250" height="157"> fonctionne bien.

    • AbsurdePhoton

      Effectivement ça fonctionne pour les squelettes, mais beaucoup moins bien à l’intérieur des articles...

    Répondre à ce message

  • Fennec72

    Bonjour,

    Est-il possible d’utiliser spiPDF pour générer un PDF à partir des réponses à un formulaire formidable et de le joindre au mail envoyé à celui qui à répondu au formulaire ?

    Merci d’avance,

    Cordialement,

    Hervé

    Répondre à ce message

  • Pi r

    Bonjour, d’après mes tests en 3.2 + spipr-dist et mpdf, le float n’est pas transmise au style des images du texte, merci

    Répondre à ce message

  • 1
    N.Salmon

    Bonjour,
    Savez-vous si le plugin est compatible avec PHP7 ?

    Merci à vous :)

    Répondre à ce message

  • 6
    conil26

    Bjr,

    Le plugin actuellement installé est signalé comme incompatible ou à vérifier pour SPIP 3.2.0 ;

    Une MàJ est-elle prévue ?

    • Maïeul

      Salut, pour ce plugin, comme pour les autres :
      -  les mainteneureuses de plugins le font bénévolement, ils n’ont pas toujour le temps de faire des tests
      -  tu peux donc leur faciliter la vie en testant les plugins sur un spip 3.2 local : il suffit simplement de modifier le paquet.xml / plugin.xml pour changer les bornes de compatibilités (lire https://contrib.spip.net/Verifier-s...
      -  si après test en local tu vois que le plugin est compatible, tu le signale (sur le forum du plugin, ou sur la spip-zone) et on marque le plugin comme compatible pour que les autres ne se posent plus la question
      - sinon effectivement il faudra attendre qu’une personne se penche sur le plugin pour le mettre à jour (cela peut être toi ! )

    • conil26

      Effectivement, passer la balise à

      <necessite id="SPIP" version="[2.0.0;3.2.99]" />

      permet de rendre ce plugin compatible SPIP 3.2.0.

    • Maïeul

      attention : cela permet d’activer le plugin. Ensuite il faut s’assurer qu’il est effectivement compatible, c’est à dire que les fonctonnalités fonctionnent. Est-ce bien le cas ?

    • conil26

      Oui, oui,

      J’ai vérifié, bien sûr ;

    • Maïeul

      Ok, parce que en fait

      <necessite id="SPIP" version="[2.0.0;3.2.99]" />

      ne rend pas le plugin compatible, mais seulement activable.

      je commite l’information,

    Répondre à ce message

  • 1
    Jérôme

    Bonjour,

    j’ai une question à laquelle je ne trouve pas de réponse. En local, j’ai mis en place mon site avec des urls propres (titre de l’article). Je souhaiterais que lors de l’exportation en pdf, le nom du fichier créé soit le titre de l’article. Cependant, je n’obtient que « articleXXX.pdf ». La solution est sûrement assez simple, mais je ne l’ai pas trouvée.

    Merci pour toute piste de réflexion !

    • Jérôme

      Mea culpa, le problème venait du squelette Escal que j’utilise et qui intègre directement les lignes de code faisant le lien avec le squelette du pdf. C’est donc les fichiers d’Escal qu’il fallait que je modifie, et non ceux de spipdf...

    Répondre à ce message

  • 1
    kent1

    Pour info je viens de publier coup sur coup deux versions :

    La première en lien avec ce commit : https://zone.spip.org/trac/spip-zone/changeset/105870/_plugins_/spipdf

    Elle permet d’utiliser le plugin un peu plus facilement de manière programmatique en ajoutant un paramètre $file à la fonction spipdf_html2pdf.

    La seconde ici : https://zone.spip.org/trac/spip-zone/changeset/105871/_plugins_/spipdf
    Elle change un chouilla les preg_match pour permettre la balise <pagebreak> ce mpdf.

    Si vous voyez des bugs, dites le moi

    Répondre à ce message

  • Yohooo

    Hello,

    Juste une petite remarque, la librairie utilisée est passée en version 7.0.
    https://github.com/mpdf/mpdf/blob/development/CHANGELOG.md

    Pour ma part, j’ai été contraint de la mettre à jour pour afficher convenablement une mise en page.
    ( les typos et des certaines fonctionnalités ne s’affichaient pas ).

    Serait-il possible de monter la version de la librairie MPF associé au plugin ?

    Répondre à ce message

  • 1
    ygornet

    salut

    à la suite du défaut constaté dans spipdf v1.0.4
    on a modifié le fichier ./spipdf.html en ajoutant un filtre :
    v1.0.4 : filename=#ENV{nom_fichier,document}.pdf
    v1.0.5 : filename=[(#ENV{nom_fichier,document}|translitteration)].pdf

    très bien

    sauf que les crochets-parenthèses ouvrant et fermant, placés au milieu d’une expression plus complexe et qui sont nécessaires dès lors qu’on ajoute le filtre
    ne permettent plus de passer la variable nom-fichier à la librairie html2pdf utilisée dans le cas qui m’occupe
    la variable « filename » est vide comme si les crochets-parenthèses ouvrant et fermant bloquait le calcul de #ENV{nom_fichier}

    conséquence les fichiers pdf qui sortent de là portent tous le même nom par défaut « document.pdf »
    et ce « document » n’est pas celui de l’expression alternative #ENV{nom_fichier,document}
    si on écrit #ENV{nom_fichier,toto} on n’a jamais un document toto.pdf

    lorsqu’on enlève les crochets-parenthèses ouvrant et fermant (et donc le filtre)
    le nom de fichier est bien transmis à filename et donc à la librairie
    et l’on obtient le nom de fichier prescrit dans l’appel de la fonction

    par ailleurs le passage de v3.1.3 à v3.1.4 a également une conséquence négative pour ce malheureux plugin
    en effet dans le fichier ./spippdf_fonctions.php, ligne 358,
    l’expressions $flux['args']['contexte']['lang'] est vide
    conséquence on a une exception dans le fichier ./lib./html2pdf/_class/locale.class.php, ligne 47
    lorsque l’on vérifie que le code de langue est bien constitué de caractère et/ou de nombre

    voili voilou des petites nouvelles du front
    bien à vous, Yanic

    • ygornet

      c’est réparé dans spipdf v1.0.6

      1) en mettant des crochets-parenthèses dans l’expression enveloppante :
      [(#HTTP_HEADER{Content-Disposition: #ENV{print, attachment}; filename=[(#ENV{nom_fichier,document}|translitteration)].pdf})]

      2) en vérifiant si $flux['args']['contexte']['lang'] a une valeur
      et sinon, en mettant par défaut 'fr'

    Répondre à ce message

  • Jérôme

    Bonjour, petit retour d’expérience sur spipdf.

    J’ai rencontré de nombreux problèmes avec spipdf pour l’affichage des images. J’ai enfin trouvé la réponse à ce souci : le problème venait de mon hébergement chez Free (je ne sais pas pourquoi). Après une installation en local, tout fonctionnait parfaitement. La solution a donc été d’investir dans un hébergement chez OVH...

    A noter que pour moi spipdf ne gère pas les images au format bmp. Mais c’est vraiment un moindre mal. Bravo pour ce plugin.

    Répondre à ce message

  • 1
    AbsurdePhoton

    Génial ce plugin, (presque) aucune difficulté à le mettre en place sur mon site.

    Mais il y a une chose qui cloche : en pré-production les fichiers PDF affichent toutes les images sans aucun problème, celles incluses dans les articles comme les autres.

    Par contre, en hébergement chez OVH les fichiers PDF affichent des petites croix (donc image non trouvée). Ce qui est très étrange c’est qu’en mode debug de spiPDF les images apparaissent bien !

    Mon environnement :

    • SPIP 3.1.3
    • SpiPDF 1.03 avec mPDF 5.7 (ça marche pareil en v6.0)
    • Seule différence entre prod et pré-prod : SSL activé chez OVH (càd tout le site est en HTTPS) et bien sûr l’adresse de base du site


    Vous pouvez tester sur mon site AbsurdePhoton www.absurdephoton.fr : allez sur un article et cliquez sur l’imprimante PDF dans le cadre « Thèmes » à droite - j’ai pour l’instant mis dans le lien le paramètre debug, de cette manière mes visiteurs obtiennent une page web simplifiée qu’ils peuvent imprimer -> il suffit d’enlever le paramètre debug dans la barre d’adresse pour obtenir la version PDF sans images.

    J’ai l’impression que ça vient des adresses en HTTPS, j’ai regardé vite fait le script mpdf.php et j’ai trouvé la partie où le HTTPS est géré, mais je ne m’y connais pas assez en PHP pour arriver à comprendre comment ça marche :(

    • AbsurdePhoton

      J’ai compris pourquoi ça ne marchait pas !

      Chez OVH en hébergement mutualisé, les adresses en http(s) ne sont pas résolues avec le nom de domaine mais avec le nom du serveur. mpdf utilise des fonctions curl en mode client web pour les images, qui ont besoin d’une résolution de nom DNS qui pointe effectivement vers le serveur. La solution est de pouvoir modifier le fichier hosts du serveur, ce qui n’est pas possible en mutualisé :(
      Source : http://stackoverflow.com/questions/23514062/mpdf-not-rendering-images-mpdf-error-image-error-could-not-find-image-file (réponse n°5)

      Pour palier ceci, j’ai été obligé de modifier le script mpdf.php, à l’endroit où il fait les remplacements d’adresses, pour faire pointer les liens au bon endroit (juste les paramètres src des images, pas les href).

      Maintenant ça fonctionne parfaitement :)

    Répondre à ce message

  • Jérôme

    Bonjour,

    Je me permet de renvoyer un message concernant les problèmes que je rencontre avec spipdf. J’utilise la version 1.0.3, avec SPIP 3.1 et le squelette Escal V3. En résumé, après de très nombreux essais :

    -  avec la librairie mpdf (versions 5.2, 5.6 ou 6.0), rien ne s’affiche sauf une page blanche.

    -  avec la librairie dompdf, le pdf est généré correctement MAIS aucune image ne s’affiche, que ce soit des images hébergées sur mon site ou des images externes (test avec les formats jpg, bmp, gif et png). Le pdf indique simplement « Image not found or type unknow ». Or, j’ai vraiment besoin de pouvoir afficher des images dans mes pdf...

    Auriez vous quelques pistes pour m’aider à résoudre mon problème. Merci beaucoup !

    Répondre à ce message

  • Bouquet

    Bonjour

    J’ai installé le plugin sur deux sites différents et exactement de la même façon et avec les mêmes paramétrages.
    Dans l’un tout fonctionne parfaitement et dans l’autre seul le contenu de l’article s’affiche sans le chemin ni le titre de l’article.

    Code : PDF

    Qu’ai-je bien pu oublier ?

    Jean-Louis

    Répondre à ce message

  • 1
    Jérôme

    Bonjour,
    J’ai eu quelques petits problèmes en installant spiPDF. J’ai résolu le conflit avec le plugin spip_bonux grâce à des conseils trouvés dans les commentaires, mais par contre le plugin ne me crée toujours aucun fichier pdf. A la place, il me crée ce qui me semble être une page html vide :
    http://jbouffand.free.fr/spip.php?page=spipdf&spipdf=spipdf_article&id_article=228&nom_fichier=article_228
    Comment faire pour résoudre ce problème ?
    J’utilise spip 3.1 et mpdf 6.0.

    merci !

    • Jérôme

      Bon, après plusieurs essais, je suis parvenu à produire un pdf. Je résume pour ceux que ça pourrait intéresser.

      Ma configuration :
      SPIP 3.1
      Escal V3
      spipdf 1.0.3
      Je n’ai réussi à faire fonctionner le plugin qu’avec la version 0.6.2 de dompdf. Pour l’instant je n’ai pas chercher plus loin.

      J’aimerai quand même savoir comment faire fonctionner le plugin avec la librairie mpdf, car j’ai l’impression a priori que tous les éléments avec la balise « float » ont disparu !
      Merci !

    Répondre à ce message

  • 2
    Julien

    PDF TRONQUE

    Sur SPIP 3.1, le PDF généré est tronqué dès la première image dans le texte...

    Voici un exemple : http://reporterre.net/Quand-les-enfants-imaginent-un-monde-sans-voitures

    Cliquez sur le PDF, vous verrez que seule l’image LOGO (la première ) est visible, le premier paragraphe, et quand on doit voir la première image jointe, plus rien !!

    Alors que le modèle spip pour le PDF est normal : http://reporterre.net/spip.php?page=article_pdf&id_article=8891&var_mode=calcul

    Une idée ? Quelle serait la balise qu’il n’aime pas avec MPDF ?

    Merci de votre aide,
    Julien

    • Yves Tannier

      Bonjour Julien,

      Ca à l’air de fonctionner ?!

    • Julien

      Non cela ne fonctionne pas sur mon poste : dans le PDF, on ne voit que la première image (avec l’enfant), et pas la deuxième avec l’assemblée, et donc ni le texte à la suite...

      Vous me confirmez que dans le PDF vous avez tout ?

      Julien

    Répondre à ce message

  • Sorensen

    Bonjour
    Excellent plugin, le rendu pdf est vraiment propre.
    Je cherche cependant à le personnaliser, et je n’ai pas trouvé comment faire pour que le texte de l’article ne soit pas centré (visuellement ce n’est pas très heureux).
    A quel endroit faut-il gérer cela ?

    Merci d’avance pour votre aide.

    Répondre à ce message

  • 2
    Alain7159

    Bonjour,

    Très bon plugin !!

    Dans la version 0.2.11, comme dans la version 1.0.1, la feuille de style personnalisée n’est pas prise en compte, alors qu’avec les feuilles de spip, il n’y a pas de souci. Avez-vous des retours identiques ?

    En utilisant un squelette personnalisé, j’obtiens dans le pdf une partie de la balise « page » : df« orientation= »L« format= »A4-L« backtop= »4mm« backbottom= »4mm« backleft= »5mm« backright= »5mm">, et pas de prise en compte de l’orientation paysage). J’ai réussi à feinter ce problème en insérant des espaces avant cette balise...

    Version spip : 3.017 en local Lamp

    • Alain7159

      Le fichier css personnalisé ne pouvait pas être pris en compte puisque j’avais mal fourni le chemin d’accès

      (#CHEMIN{perso.css} au lieu de #CHEMIN{css/perso.css}

      -  Après cette rectification, je me retrouve avec ce message si j’utilise mpdf :
      « Can’t open file lib/mpdf/ttfontdata/dejavusanscondensedB.GSUBGPOStables.dat ».
      -  Si j’utilise html2pdf : « Le type de fichier document texte brut (text/plain) n’est pas pris en charge ».

      Je ne vois rien dans mes fichiers (particulièrement le css perso) qui puissent engendrer ce type de message.

      Si quelqu’un a une idée, je suis preneur. Merci.

    • Yohooo

      Bonjour Alain,

      Le dossier lib/mpdf/ttfontdata sert à placer les fichiers relatifs aux typographies visibles dans test pdf

      Il faut tout simplement donner un acces en écriture à ce dossier pour voir disparaître ce message d’erreur.

    Répondre à ce message

  • 2
    Jean-Jacques

    Bonjour,
    J’aimerais que le pdf généré soit « protégé ».
    La doc de la librairie mpdf stipule qu’il faut employer SetProtection
    void SetProtection ( array $permissions [, string $user_password [, string $owner_password [, integer $length ]]])

    Est ce qu’il est possible d’agir sur le plugin, au moment ou il passe les paramètres à la libraire ?
    Enfin bref comment faire svp ?
    Merci !

    • Yves Tannier

      Bonjour,

      Dans le fichier spipdf_fonctions.php avant $mpdf->WriteHTML($html) ; vous pouvez essayer ajouter $mpdf->SetProtection(vos options) ;

      Je n’ai pas testé ;)

    • Jean-Jacques

      Bonjour,
      Merci beaucoup. Ci dessous un copier coller du code modifé

       // la classe mPDF
                $mpdf = new mPDF(SPIPDF_CHARSET, $format_page, 0, "", $backleft, $backright, $backtop, $backbottom, $margin_header, $margin_footer);
                $mpdf->SetProtection(array());
                $mpdf->WriteHTML($html);

      Sans options supplémentaires on peut ouvrir le pdf, mais pas l’imprimer, pas le copier, etc,
      donc c’est génial et cela correspond avec ce que le client (un peu parano .. ) m’a demandé
      En cas de mise à jour du plugin, j’imagine que mes modifications seront perdues ?
      Est ce qu’il y a un mécanisme de surcharge du code du plugin ?
      Encore merci !

    Répondre à ce message

  • 1
    Julien

    TEXTE TOUJOURS CENTRE !

    Désolé de demander ceci mais je ne vois pas :
    -  voici le modèle HTML :
    http://ussolidaires.fr/spip.php?page=pdf_attestation&id_inscription=25&nom_fichier=attestation_Koita

    -  Voici le résultat :
    http://ussolidaires.fr/spip.php?page=spipdf&spipdf=pdf_attestation&id_inscription=25&nom_fichier=attestation_Koita

    Pourquoi donc le texte est-il centré dans le PDF ??

    Merci de votre aide.
    Julien

    • Julien

      Je ferme le ticket ! Le contenu dans un TD est centré...

      Ceci dit je n’arrive pas à l’aligner à gauche : align=left, style=« text-align:left » pour le TD garde le texte centré...

      Je supprime le tableau !

    Répondre à ce message

  • Ysabeau

    Le plugin, très bien rien à dire. Merci.
    En revanche mon hébergeur m’a signalé un malware dans le librairie mpdf !

    Répondre à ce message

  • maurice

    salut
    pour moi, ça ne fonctionne toujours pas, il y a encore des problèmes
    j’aurai bien voulu poster deux pdf d’articles.
    mais ne sachant où poster
    vous pouvez essayer de sauvegarder l’article, ici :

    http://fractuscontrarius.fr/spip.php?article37&lang=fr
    ou
    http://fractuscontrarius.fr/spip.php?article35&lang=fr

    amicalement, momo

    Répondre à ce message

  • 1
    momo

    bonjour

    spiPDF

    j’ai donc toujours dans mon espace privé

    Erreur dans les plugins : /var/www/clients/client0/web1/web/plugins/svn/spipdf/spipdf.php
    et les caches vidés, via ssh, ou ftp et sur le site, et dans le navigateur

    et ce matin j’ai donc sauvegardé quelques articles en pdf via ce plugin
    es codes informatiques n’apparaissent pas
    ce sont les textes avec

    <cadre>et


    on a juste un petit rectangle blanc de 4 mm
    idem pour les liens informatiques
    voir article pour faire un essais de sauvegarde

    http://fractuscontrarius.fr/spip.php?article32&lang=fr
    bonne journée à tous

    Répondre à ce message

  • Pierre KUHN

    Bonjour,

    Comment faire un changement de page avec ce plugins ?
    Si je veux passer 2 articles et obliger le second a être sur une autre page.

    Répondre à ce message

  • 2
    Manu

    Pb de path dans le cadre d’une mutualisation SPIP ?
    Bonjour,
    J’ai droit au message Impossible de trouver la librairie de génération de PDF mpdf. vérifiez que vous l’avez bien téléchargée et installée dans /lib
    Pourtant, le répertoire mpdf existe bien dans /lib
    => Est-ce dû au fait que ce plugin soit utilisé dans le cadre d’une mutualisation SPIP que la détection de la présence des librairies échoue ? Au contraire, quelles sont les autres pistes à explorer (ou quelque chose que je n’ai pas bien fait) ?
    Merci (beaucoup) d’avance...

    • Francky

      Bonjour :-)
      Sans connaître la réponse à ton problème, tu devrais regarder la version de la lib mpdf que tu dis avoir.
      Dans l’article, il est dit que des essais on été fait avec la version 5.3 !
      http://mpdf1.com/repos/MPDF53.zip

      Mais la dernière version de la lib est la : 5.7.4, donc possible que qu’il a des changements dans la lib qui demanderaient des modifs dans le plug.
      http://www.mpdf1.com/mpdf/index.php?page=Download

    • Manu

      Bon, je suis revenu à la version 5.3
      Mais, aïe, page blanche (erreur 500)

      mon url : spip.php?page=spipdf&spipdf=toto_pdf&nom_fichier=toto_pdf

      pourtant j’ai un « template » toto_pdf.html minimaliste :

      <page lib_pdf="mpdf" orientation="P" format="A4" backtop="7mm" backbottom="7mm" backleft="10mm" backright="10mm">
Hello world !
</page>

      Qu’est-ce qui peut être en cause ? Quelque chose que je fais mal ?

    Répondre à ce message

  • RealET

    Bonjour,

    Pour information, le plugin fonctionne avec la version 6.0 de mPDF : http://www.mpdf1.com/mpdf/index.php?page=Download

    Merci pour ce plugin !

    Répondre à ce message

  • 3
    Benji

    Bonjour !
    J’utilise ce plugin pour réaliser une compilation d’articles. ça marche vraiment très bien. J’ai essayé de faire un sommaire et ça fonctionne sauf que le sommaire se répète pour chaque article, du coup je l’ai en plusieurs exemplaires alors que je voudrais seulement l’avoir en page 1. Est-ce que quelqu’un sait comment faire ça et pourrai me donner un petit coup de main ?
    Merci pour le plugin en tout cas.

    • Benji

      Je me réponds à moi-même : j’avais conçu mon sommaire avec une boucle SPIP. Finalement, il fallait sortir ma boucle sommaire de la boucle principale pour l’afficher une seule fois. Donc ça marche.

      Seulement je m’aperçois que j’ai mal raisonné du départ car il existe une fonction INDEX avec BOOKMARKS qui permet d’afficher automatiquement un sommaire avec les liens vers les pages des articles. J’ai vu ça dans le wiki de la librairie mpdf mais je ne vois pas comment l’activer dans Spipdf.Je suppose qu’il faut ajouter quelque chose dans le fichier spipdf_fonctions.php.
      Est-ce que quelqu’un sait le faire ?

    • Yves Tannier

      Bonjour,

      Je suppose qu’il faut plutôt ajouter les bookmarks dans le squelette ? http://mpdf1.com/manual/index.php?tid=118

      Dans la boucle spip qui construit votre sommaire puis dans l’article. Je dirai.

      Je n’ai pas testé ;)

    • Benji

      Merci pour ce retour Yves. En fait j’ai plutôt utilisé les possibilités offertes par MPDF. J’ai bien lu la doc (c’est plutôt complet) et j’ai trouvé comment créer un index de bookmarks et un sommaire avec des ancres en introduisant quelques lignes supplémentaires dans spipdf_fonctions.php et dans ma page spipf_compil.html.
      ça marche très bien.
      MERCI pour ce plugin très utile et vraiment très puissant !

    Répondre à ce message

  • 1
    Amaury Adon

    Bonjour
    Tout d’abord merci pour ce très bon plugin.
    J’ai cependant un souci. Je dois éditer un PDF contenant une carte GIS mais il se trouve que celle-ci n’apparait pas dans le PDF généré alors qu’elle apparait bien avec l’option débug activée.

    Est-ce que c’est un problème de javascript (je crois comprendre que les carte GIS sont rendues côté client) et si oui, y a-t-il un contournement possible.

    Précision, j’utilise la librairie mpdf.
    Merci pour vos éclaircissements si vous en avez.

    • Yves Tannier

      Bonjour,

      Effectivement, le javascript n’est pas interprété. Je n’ai pas de solution à vous proposer hormis la génération d’une « vraie » image à la place du javascript.

    Répondre à ce message

  • 1
    Jean Christophe Villeneuve

    Bonjour

    Merci pour ce plugin qui semble plus performant que Article-PDF

    Néanmoins, j’ai un petit souci avec les images qui se retrouvent toutes à gauche avec la première ligne du texte en bas à droite de l’image et le reste du texte en dessous, que l’image soit à gauche, au centre ou à droite dans l’article.

    Une idée pour y remédier ?

    Répondre à ce message

  • 3
    katmandou

    C’est bon j’ai trouvé, il faut rajouter dans le lien :

    |parametre_url{debug_spipdf,1}

    Par contre j’ai un autre problème, j’ai un livre à convertir en PDF, mais au bout de d’un peu plus d’une dizaine de pages, le contenu est vide !
    Je suis obligé de scinder le livre en petit chapitres, et de le convertit chapitre par chapitre.
    N’y aurait-il pas un moyen pour augmenter la taille des buffers ?

    • Yves Tannier

      Ce problème est lié au preg_replace_callback trop gourmant. Mais je crois que vous l’aviez découvert seul vu mon délai de réponse ;)

    • rburton

      Bonjour,

      et quelle est la solution ?
      Merci,
      Roger Burton

    • Benji

      Oui, moi aussi cela m’intéresserais de savoir. J’ai une compilation d’articles à réaliser mais ils sont tous tronqués au bout de 2 ou 3 pages.... Est-ce que quelqu’un peut éclairer ma lanterne avec le preg_replace_callback ? Je n’y connais rien en PHP... Merci d’avance...

    Répondre à ce message

  • 2
    Teddy Payet

    Bonsoir,

    Comment ce plugin gère les polices ?
    Si notre PDF doit utiliser une « Frutiger » par exemple, sa déclaration dans les feuilles de style suffira ?

    • Yves Tannier

      Je n’ai jamais essayé mais si vous utilisez mPDF, il doit-être possible d’intégrer d’autres polices comme expliqué sur le manuel : http://mpdf1.com/manual/index.php?tid=453

    • Teddy Payet

      Bonjour,

      Je serai plutôt tenté par html2pdf car il a l’air plus sympa pour la gestion des bookmark, pagehead, pagefoot, etc.
      Actuellement, dans le plugin spiPDF, je n’ai pas l’impression qu’on puisse créer les index du PDF généré. Et bien entendu, les lib supportés par le plugin ne gèrent pas la création d’index de la même façon...

    Répondre à ce message

  • 2
    bruno31

    bonjour

    J’ai un truc bizarre depuis un bon moment. Mais aujourd’hui, je suis bien coinçé.

    Si je remplace une image, c.a.d que je conserve le ID du document mais j’upload un nouveau fichier en remplacement, et bien j’ai bien la mise-à-jour dans la page HTML générée par SPIP, avec le squelette article.html,
    mais SPIPDF persiste à me mettre l’ancienne version de l’image.

    J’ai bien effacé /local, /tmp, le cache du navigateur, .... Rien n’y fait.

    Si j’ajoute debug_spipdf=true pour voir le code HTML généré avant la conversion en PDF, le problème est déjà présent dans le HTML. Donc cela ne vient pas de mPDF.

    J’appelle avec l’url :
    http://monsite.com/spip.php?page=spipdf_article&spipdf=spipdf_article&id_article=133&var_mode=calcul&nom_fichier=guide&debug_spipdf=true

    Donc avec cette url, j’ai l’ancienne version de l’image. NOK

    Si je remplace par page=article
    J’ai bien la nouvelle image. OK.

    Tout se passe comme si SPIPDF utilise un cache qui lui est propre ?

    • bruno31

      J’ai un peu progressé :

      J’ai découvert que l’anomalie est liée à la présence du filtre abs_url appelé avant le image_reduire.

      Si je le supprime, j’ai bien la dernière version de l’image.

      Maintenant, reste à comprendre pourquoi ?

    • Yves Tannier

      Bonjour. Effectivement, c’est étrange mais ça doit plutôt provenir du cache image de SPIP. Car le debug_spipdf affiche le HTML de SPIP avant qu’il soit envoyé à mPDF.

    Répondre à ce message

  • 1
    katmandou

    Bonjour,
    Il y a un bug qui empêche de créer des pages longues (ex : chapitre d’un livre).
    En supprimant le ligne 162 du fichier spipdf_fonctions.php, le problème est réglé, mais quid des images flotantes (que j’ai remplacés pas des tableaux à cause des bugs de mpdf).

    //	$html = preg_replace_callback($patterns_float, !empty($params_pdf['float']) ? 'spipdf_remplaceSpan' : 'spipdf_remplaceSpan_wfloat', $html);
    • Yves Tannier

      Bonjour,

      Oui, effectivement avec le preg_replace_callback il y un souci avec les documents longs. Je note pour corrections futures.

    Répondre à ce message

  • 1
    Teenoo

    Bonjour,

    le plugin fonctionne apparemment pour des sites en HTML4, quid des sites en HTML5 ?

    Merci :)

    • Teddy Payet

      Bonjour,

      Je ne sais pas si cette question est toujours d’actualités mais voici une réponse :

      Quand l’auteur ici parle d’HTML4, ce n’est pas pour les squelettes du site mais les squelettes qui génèrent le pdf… Donc, non, pas de html 5 pour les squelettes qui génèrent les PDF mais toujours et uniquement pour le moment (selon l’avancée des librairies) en HTML4.

    Répondre à ce message

  • 1
    bcaron

    Bonjour,
    Ma config :
    spiPdf 0.2.4 pour spip 3.
    mpdf 5.7

    je désire afficher en mode paysage.
    J’ai modifié le source de :
    spipdf_article.html
    et remplacé dans la balise page, l’attribut orientation=« P » par orientation=« L »
    L’affichage est toujours en portrait.
    Comment faire ?
    Merci pour votre aide.
    BC

    • bcaron

      En regardant le code , on voit qu’en fait orientation n’est pas utilisé par le plugin, bien qu’utilisé dans l’exemple de la génération pdf d’un article.
      pour passer en mode Paysage il faut mettre -L en plus dans le format : A4-L

    Répondre à ce message

  • katmandou

    Bonjour,
    Comment afficher le résultat du pdf dans une page html pour le debug ?
    C’était possible avant, mais je ne me rappelle plus comment faire !
    Merci.

    Répondre à ce message

  • Teenoo

    Bonjour,

    mon spiPDF est intégré par un inclure dans un article.html. Or même avec

    <INCLURE{fond=inclure/arboart,id_rubrique,titre=#TITRE}{id_article=#ID_ARTICLE} ></INCLURE>

    Ou

    <INCLURE{fond=inclure/arboart,id_rubrique,id_article,titre=#TITRE} ></INCLURE>

    L’id de l’article n’est pas retourné et le PDF non généré. A la place j’ai une erreur :

    Not Found
The requested URL /construction/{id_article} was not found on this server

    Comment remédier à cela sans intégrer le code directement ? Merci

    Répondre à ce message

  • Francky

    Hello :-)
    Il y a un problème dans l’article. En effet dans la colonne de droite, il y a 3 zip, alors qu’il ne devrait y en avoir qu’un...
    Il y a un zip pour la version 0.2.2 un autre pour la 0.2.3 et enfin un autre pour la 0.2.4

    Si je regarde dans :
    http://zone.spip.org/trac/spip-zone/browser/archivelist.txt#L919

    Il ne devrait y avoir un zip « que » pour la version 0.2.4
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/spipdf/branches/v0.2/plugin.xml

    Surtout qu’il n’y a pas de zip « actif » qui pointe dans archivlist vers la 1.0.0 (la trunk)
    http://zone.spip.org/trac/spip-zone/browser/archivelist.txt#L920
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/spipdf/trunk/paquet.xml

    Répondre à ce message

  • 2
    Pierre KUHN

    Bonjour

    Est ce que le plugins fonctionne actuellement chez certain ?
    Perso j’ai pas de chargement de librairie.

    Répondre à ce message

  • 4

    Bonjour,

    Sur une install en Spip 3.0.11 j’ai le message suivant avec mpdf 5.7.1
    Fatal error: Cannot redeclare array_insert() (previously declared in /httpdocs/plugins/spip-bonux-3/spip_bonux_options.php:99) in /httpdocs/lib/mpdf/includes/functions.php on line 27

    • Reynald Beaufort

      Bonjour,

      J’ai exactement le même message d’erreur lors de mes tests en local avec les mêmes versions de Spip et de mpdf

      Fatal error : Cannot redeclare array_insert() (previously declared in E :\www\te_test_v3-0-11\plugins\auto\spip_bonux\v3.0.5\spip_bonux_options.php:99) in E :\www\te_test_v3-0-11\lib\mpdf\includes\functions.php on line 27

      Quelqu’un aurait-il une solution ?
      Merci

      Reynald

    • Cela fonctionne avec mpdf 5.6

    • Reynald Beaufort

      Merci ! ça marche bien mieux avec mpdf 5.6... J’ai juste un problème pour l’intégration des images dans le texte, elle sont positionnées correctement, mais pas entourées par le texte (mais ça je crois que c’est normal c’est la librairie qui ne gère pas) , en outre, le titre et le descriptif n’apparaissent pas, et ceci, que j’utilise la balise ou . Le plugin « Insérer modèles » avec « Modèles média » est activé.

      Je continue à chercher mais si vous avez une suggestion...

      Reynald

    • bruno31

      Bjr

      Il suffit de renommer la fonction array_insert -> array_insert2

      -  fichier \LIB\MPDF\mpdf.php
      Line 22928 - array_insert2($textbuffer, $a1, $found+1) ;
      Line 22929 - array_insert2($textbuffer, $a2, $found+2) ;
      -  fichier \LIB\MPDF\includes\functions.php
      Line 4 - function array_insert2(&$array, $value, $offset)

    Répondre à ce message

  • Christophe

    Une remarque au sujet de l’utilisation de <pagebreak ></pagebreak> pour réaliser des sauts de page.
    Je ne parviens pas à faire fonctionner cette commande, en revanche en utilisant <tocpagebreak ></tocpagebreak> le saut de page fonctionne, mais il se comporte bizarrement puisqu’il introduit une page blanche sans raison apparente.

    J’ai donc modifié la ligne 220 du fichier « spipdf_fonctions.php » qui est à l’origine :
    $html = preg_replace('/<\/?page(.*)>/iUms', '', $html);

    par
    $html = preg_replace('/<\/?page>/iUms', '', $html);

    afin que <pagebreak ></pagebreak> soit reconnu.
    Cette modification est fonctionnelle et il n’y a pas le problème de la page blanche insérée par <tocpagebreak ></tocpagebreak>.

    Répondre à ce message

  • tofulm

    Bonjour,

    Merci pour le plugin,

    si dans un plugin, il y a un inclure, cela ne fonctionne pas.

    Quelqu’un a t’il trouvé une solution ?

    Répondre à ce message

  • 2
    Ivan

    Merci pour ce plugin, qui va je l’espère me permettre de prendre en compte les caractères chinois (pour l’instant je n’arrive pas encore à les afficher).

    Mon soucis est le suivant :
    Jusqu’à présent je générais mes pdf avec le plugin article_pdf.
    Avec article_pdf, mes pdf comportent dans un seul fichier toutes les découpages par page créés par le couteau suisse, alors qu’avec spipdf ce n’est pas le cas. Je retrouve dans le pdf la pagination visible sur le site, ce qui n’est pas le but.

    Je vais chercher comment régler ça, mais si vous avez une piste, je suis preneur ! :)

    • Yves Tannier

      Bonjour,

      Je dirai que la piste est à chercher dans les options de la librairie PDF que vous avez choisi. Il suffit parfois d’ajouter des balises au début du squelette.

    • Ivan

      Merci Yves. En effet j’avais résolu le problème de pagination en échappant le traitement par l’appel d’une CSS pour le Print.
      Il me reste maintenant à arriver à afficher les caractères chinois (c’est quand même l’intérêt principal de cette librairie), chose qui semble pas tout à fait évidente.

    Répondre à ce message

  • 1
    graphie

    Bonjour,

    J’ai un souci avec les formulaires qui sont générés en PDF : ils sont très beaux mais ne comportent aucune des valeurs saisies dans les champs :-(

    Y a-t-il une subtilité de paramètrages propre aux articles contenant des formulaires ?

    Voici le code de mon squelette article :

    <BOUCLE_PDF(ARTICLES){id_article}>
<a href="[(#URL_PAGE{spipdf}
|parametre_url{spipdf,article-pdf}
|parametre_url{id_article,#ID_ARTICLE}
|parametre_url{nom_fichier,Fiche-#ID_ARTICLE})]" title="télécharger le fichier PDF">PDF</a>
</BOUCLE_PDF>

    merci pour vos conseils,
    françois

    • Yves Tannier

      Bonjour,

      Je n’ai jamais essayé de générer de PDF à partir d’un formulaire mais je dirais qu’il faut pouvoir passer les valeurs saisies au squelette du PDF.

    Répondre à ce message

  • 5
    Déesse A.

    Merci pour ce plugin qui répond à un vrai besoin, mais qui m’a finalement montré qu’il y avait une faute de conception dans le code de SPIP, car devoir réécrire chaque squelette n’est pas une solution satisfaisante. Moralité, j’ai changé légèrement le code de SPIP 2.1 et je donne dans le message explicatif un code de quelques lignes qui permet la prévisualisation PDF quel que soit le squelette utilise.

    Ce petit code n’est pas aussi générique qu’il le faudrait en ce qui concerne les bibliothèques. Je n’ai par ailleurs pas vu (faute d’avoir regarder ton code) en quoi il y avait besoin de « nettoyer » le HTML produit par SPIP. Je suis par ailleurs pas satisfait de ce que donne mPDF qui semble ignorer trop de choses de mes CSS (en particulier le page-break), mais c’est peut-être faute de ne pas avoir assez lu la doc.

    • Yves Tannier

      Bonjour,

      C’est intéressant ! Est-ce bien fonctionnel ? Car dans mon plugin, j’ai du ajouter des expressions régulières pour modifier à la volée du HTML généré par SPIP...

    • Yves Tannier

      Bon, j’avais lu la moitié du post ;)

      c’est par exemple sur la gestion de certaines balises HTML que les librairies HTML->PDF ont du mal (exemple les <dt> <dl>).

    • Déesse A.

      Oui c’est fonctionnel, mais il faut la 2.1.22 minimum (qui par ailleurs comble un trou de sécurité donc c’est fondamental de mettre à jour ; il y a même une 2.1.23 maintenant).

      Par ailleurs le dernier message est illisible, il faut utiliser la balise « code » ou transcoder soi-même les chevrons ouvrants avec &lt; pour rendre un source Html lisible.

    • Yves Tannier

      Ah oui ! je disais donc les <dl> et les <dt> posent (posaient ?) problème

    • Déesse A.

      Perso je n’utilise pas Dl et Dt mais rien n’empêche de rajouter un pré-traitement dans la fonction de prévisualisation que je donne dans l’envoi cité en référence. Mon impression est que ce plugin mériterait une nouvelle version (précisant que son intervalle de compatibilité commence avec la 2.1.22) ne comportant plus aucun squelette mais seulement la fonction dont je parle enrichie des nettoyages nécessaires s’il en reste.

      Depuis mon premier message je n’ai pas pu regarder plus avant mPdf, en particulier j’aurais voulu forcer d’entrée un affichage à 4 pages par feuille, mais il ne m’a pas semblé qu’il avait cette fonctionnalité. Je suis preneur de toute piste, avec mPdf ou autre.

    Répondre à ce message

  • 4
    le cancre

    Bonjour,

    La génération du PDF pose problème lorsque j’ai <imgXX|center>, et fonctionne lorsque j’ai <docXX|center>.
    Je me résous donc à utiliser le second, pas de souci. Seulement, je ne parviens pas à faire afficher le titre/la légende de l’image. Elle apparaît sur le site, mais pas sur le fichier généré.

    Je me dis donc qu’il s’agit d’une modification que je dois apporter au squelette.
    Avez-vous une idée de ce qu’il faudrait que je modifie dans le squelette de spipdf_artcle.html pour que les légendes s’affichent lorsque j’ai <docXX|center> ?

    Merci par avance pour vos lumières.

    BM

    • le cancre

      Personne n’a d’idée :-( ? Même une piste ?
      Merci par avance
      BM

    • Yves Tannier

      Bonjour,

      Quel est précisement le souci avec <imgXX|center> ?

    • le cancre

      Bonjour,
      Oui, pardon, c’est vrai que je nai pas précisé. Je l’exposais en réponse à un post précédent de Chris.

      Parfois - ce n’est pas systématique -, le PDF généré n’affiche pas certaines images et une partie du texte. Je ne comprends pas pourquoi. Lorsque je remplace, dans les articles incriminés, <imgXX|center> par <docXX|center>, le PDF généré est impeccable.
      Impeccable sauf que je ne parviens pas à faire afficher le titre et la description de l’image (sur le site, elle est affichée automatiquement sous le document/image).

      MAIS, parce qu’il y a un « mais », c’est à n’y rien comprendre, je viens de tenter de reproduire le bug sur un article en ligne, pour que vous puissiez visualiser... eh bien cela fonctionne désormais. Je n’ai pourtant rien modifié du code... A priori donc, c’est résolu sans que je ne comprenne trop pourquoi...

      Merci à vous en tout cas de vous être penché sur mon problème, cela aura eu l’effet de tester à nouveau pour m’apercevoir que cela fonctionne désormais.

      BM

    • Yves Tannier

      Tant mieux si ça fonctionne. Il y a effectivement des problèmes erratiques avec la génération du PDF via le code généré par SPIP.

    Répondre à ce message

  • 3
    alinet

    Bonjour sur un SPIP 2.1 avec la lib mpdf toute fraichement télécharger, mise dans lib, je me prend deux warning qui empeche la génération du pdf

    Warning : require_once(lib/mpdf/config_cp.php) [function.require-once] : failed to open stream : No such file or directory in
    /htdocs/monsite/lib/mpdf/mpdf.php on line 39

    Fatal error : require_once() [function.require] : Failed opening required ’lib/mpdf/config_cp.php’ (include_path=’. :/Applications/MAMP/bin/php/php5.2.17/lib/php’) in htdocs/monsite/lib/mpdf/mpdf.php on line 39

    Merci de votre aide

    • alinet

      en ouvrant le ficher mpdf.php à la ligne 39
      j’ai require_once(_MPDF_PATH.’config_cp.php’) ;
      Merci

    • Yves Tannier

      Bonjour,

      C’est peut-être lié à la nouvelle version de mpdf... Je vais vérifier dès que possible.

    • Déesse A.

      J’ai rencontré le même problème, mais c’est faute d’avoir mal lu la page de download mpdf. Le lien « Download » à côté de « 5.6.1 » est juste une mise à jour de 2 fichiers, il faut d’abord charger la 5.6 dite « full version », puis la 5.6.1 à part et utiliser ses 2 fichiers pour écraser les 2 correspondants dans la 5.6.

    Répondre à ce message

  • 1
    Chris

    Bonjour,
    J’ai une partie du document qui n’est pas affichée !
    Ce n’est pas du à un texte trop long (je l’ai raccourci pour vérifier), et après maints essais, je me suis aperçu que ça venait des images flottantes (qui sont pas flottantes dans mon, pdf).
    Par exemple 2 images centrées, suivis d’une image à gauche, le tout entrecoupé de texte, dans ce cas tout ce qui est entre la 1re image centrée et l’image à gauche disparaît !
    C’est très gênant, car je dois générer mes pdf si possible tels qu’ils sont affichés sur la page web.

    J’ai mis à jour les versions, mais cela ne change rien, j’ai spip 2.1.20, spipdf 0.2.2 et mpdf 5.6.1

    Merci pour votre aide.

    • le cancre

      Bonjour Chris,
      Je rencontrais très récemment le même problème. Avec <imgXX|center>, le PDF supprimait du texte (et certaines images (??)).
      En utilisant <docXX|center>, le PDF est généré tout à fait correctement... sauf qu’il n’affiche pas les titres des images :-(
      Je m’en vais donc poser la question, dans le cadre un peu plus haut ;-)
      BM

    Répondre à ce message

  • 2
    Polar oïd

    Bonjour, merci pour ce plugin qui fonctionne parfaitement, testé sur les articles... J’aimerais réaliser un PDF sur mesure qui contiendrait les informations contenues dans la table spip_auteurs et qui retournerait les données d’un auteur en session, c’est à dire connecté via le formulaire de login...

    Aprés plusieurs tentatives, je ne parviens pas au résultat désiré étant donné que je ne comprends pas le principe de base qui permet de transférer les valeurs d’une table via le paramétrage de l’url de génération du .pdf

        <a href="[(#URL_PAGE{spipdf}
            |parametre_url{spipdf,spipdf_profil}
            |parametre_url{id_article,#ID_ARTICLE}
            |parametre_url{nom_fichier,Profil})]"></br>
    Votre profil en PDF</a>

    Que faut-il indiqué à la place de

      |parametre_url{id_article,#ID_ARTICLE}

     ?
    J’ai testé avec :

      |parametre_url{id_auteur,#ID_AUTEUR}

    et coté squelette (spipdf_profil), une boucle de type :

    <BOUCLE_Profil(AUTEURS){id_auteur}>

	 [(#ID_AUTEUR)] 
	 [(#NOM)] 
	 [(#BIO)] 
	 [(#EMAIL)] 

</BOUCLE_profil>

    Mais le pdf généré n’affiche rien...

    Des idées ? Merci d’avance ;)

    • Yves Tannier

      Bonjour,

      Ca devrait fonctionner de cette manière. Avez vous essayer d’ajouter votre boucle Profil dans le squelette fourni spipdf_article.html en gardant les éléments de style et de configuration du PDF (balise page) ?

    • Polar oïd

      Salut, merci pour votre réponse, j’ai en effet testé en conservant le squelette d’origine spipdf_article.html mais rien... J’ai donc testé autrement :

      <BOUCLE_Profil(spip_auteurs){id_auteur}>
         [(#NOM)]
</BOUCLE_profil>

      Étrange, cela fonctionne... Mais, je ne suis pas au bout de mes recherches. En effet, j’aimerais savoir si il est possible de passer un id_auteur au squelette ? l’idée serait de disposer d’une liste des auteurs en base et dont les liens généreraient un .pdf pour chaque profil, qu’en pensez-vous ? Grâce à :

      <BOUCLE_Profil(spip_auteurs){tout}{id_auteur=#SESSION{id_auteur}}>
 [(#NOM)]
</BOUCLE_profil>

      On peut produire un .pdf de l’auteur en session mais ce sont bien les profils de tous les auteurs que je cherche à obtenir avec un squelette unique...

      Avez vous des pistes ? ;)

      Récapitulatif :

      -  on fabrique une boucle auteurs qui retourne une liste de l’ensemble des auteurs sous forme de liens

      -  on clique sur un lien correspondant à un auteur donné

      -  on génère un .pdf contenant les donnés de l’ id_auteur spécifiquement

    Répondre à ce message

  • 1
    Marc P

    Bonjour, juste pour signaler que le lien pour télécharger la librairie mpdf renvoie sur une erreur.
    La bonne adresse est :http://www.mpdf1.com/mpdf/index.php

    Répondre à ce message

  • 2
    Brice

    Bonjour,

    Je tente de préciser un nom de fichier qui reprenne le titre de l’article. J’essaie donc dans les paramètres url de #URL_PAGE :

    |parametre_urlnom_fichier,(#TITRE|couper15)

    (je m’excuse par avance, je n’ai pas de balises ici pour indiquer qu’il s’agit de code...)

    Supposons que mon titre commence par « La restitution des suivis... », je devrais donc avoir « La restitution.pdf », n’est-ce pas ? Malheureusement, quel que soit ma troncature, j’ai « La.pdf » comme si le nom attribué s’arrêtait automatiquement au premier espace. Dois-je changer quelque chose au code d’un fichier quelque part pour empêcher cela ou est-ce que je m’y prends mal ?

    Merci par avance de vos lumières :-)
    Cdlt,
    BM

    • Yves Tannier

      Il faut peut-être mettre entre guillemet le titre tronqué. Il n’y a pas d’intervention au niveau du plugin sur ce paramètre (voir dans spipdf.html => c’est là qu’est utilisé nom_fichier)

    • Brice

      Bonsoir,
      Merci Yves et merci robomatix pour vous être penché sur mon problème. J’ai essayé avec vos solutions, tout au moins avec ce que j’en ai compris, mais n’y suis pas parvenu. Soit qu’elles ne fonctionnent pas, soit que je suis trop ignare...

      Malgré tout, j’ai réussi. Si cela peut en aider d’autres, voici comment jai procédé :
      initialement, les URL des articles finissaient par « article12 » ou « article12html » je ne sais plus. Bref, pas par le titre de l’article. J’ai donc modifié via « Configuration » et j’ai mis « propres » pour le « type d’adresses URL » (je suis sous SPIP 2.1.19).
      J’ai ensuite utilisé #SELF dans les paramètres pour spipdf, de cette manière :

      |parametre_url[nom_fichier,#SELF]

      (remplacer les crochets ici par des accolades)
      (en passant, comment faîtes-vous apparaître le code SPIP sur les posts ??)

      De cette manière, cela fonctionne.
      Merci à vous.
      BM

    Répondre à ce message

  • 7
    Brice

    Bonjour,
    et bravo pour ce plugin extrêmement utile, notamment dans le cadre de l’édition électronique (mais pas que).

    Dans son utilisation toutefois, je suis confronté à un problème assez bizarre.
    Quelques-uns de mes articles comportent des tableaux. Leur mise en forme passe totalement à la trappe sur la version en ligne de mon site... alors qu’en local, leur css est bien pris en compte.

    Pour exemple, dans le fichier spipdf_article.html, à l’endroit des « quelques styles en plus », j’ajoute :
    table margin-top : 10px ;border : 5px solid red ;border-collapse : collapse ;
    Certes, c’est laid, mais c’est pour tester.

    Eh bien en local (WAMP) mes tableaux, dans le PDF, sont bordés de rouge, alors qu’en ligne ils sont complètement nus, pas même une bordure à se mettre sur le dos ! Je précise que mes deux versions de SPIP et de plugin sont strictement identiques en ligne et en local.

    Une idée sur la cause de cette bizarrerie ?

    Merci par avance pour vos lumières :-)
    BM

    • Yves Tannier

      Bonjour,

      Vérifiez les différentes versions de PHP entre votre serveur local et distant peut-être une piste.

    • Brice

      Merci pour votre réponse.
      En local (tableaux OK) : version 5.3.5
      En distant (tableaux pas OK) : version 5.3.18

      Il s’agit de PHP 5 pour les deux. Bizarre...

      Je continue à chercher... Si quelqu’un a une idée, qu’il n’hésite pas ;-)

    • Brice

      C’est encore moi...

      Bonjour,
      Je me bats toujours avec mon problème de tableaux (cf. message un peu plus haut).
      Je ne crois pas que le problème vienne de PHP (5.3 en local comme en distant).
      Je pencherais pour un problème de feuille de style. En distant, les styles en semblent pas appliqués.
      Je joins une image, c’est toujours plus simple d’avoir la reproduction sous les yeux pour comprendre le « dysfonctionnement ».

      S’il s’agit effectivement d’un problème de liens vers une feuille de style (sachant que même les styles déclarés directement dans spipdf_article.html ne sont pas pris en compte en distant), comment résoudre ce problème ? Cela peut-il être lié au fait que le SPIP distant ne soit pas à la racine du site, alors qu’en local il l’est ?

      Merci vivement par avance à quiconque pourra m’enlever cette épine du pied.

      BM

    • Brice

      Bon, ben c’est réglé... Comme bine souvent la solution était sous mes yeux...
      En plus de mon problème de tableaux, j’avais un souci avec les images qui ne s’affichaient pas... Forcément, mon site distant étant en test, il est protégé via htaccess... Supprimer cette « protection » résout les problèmes et de tableaux et d’images. Si d’autres rencontrent ce problème finalement tout bête... J’en rougis de honte.

      BM

    • Yves Tannier

      J’aime quand les problème se résolvent d’eux même :)

      Surtout qu’en ce moment je mets un peu de temps à répondre !

    • Brice

       :-) Cela force à réfléchir un peu par soi-même !

      En revanche, mon problème du 21 novembre (nom de fichier) reste à résoudre ;-) J’ai beau me creuser les méninges, je ne vois pas, pour le moment.

      Merci Yves quoi qu’il en soit pour ce super plugin.

      BM

    • robomatix

      Pour le nom du fichier, essais un truc du genre

      nom_fichier,(#TITRE |replace{"'",""}|substr{0,15})

      Je crois que couper foire un peu si on coup trop court... Le replace, c’est pour supprimer le ’ .
      Pas sur que ça marche, mais peut être une piste à explorer....

    Répondre à ce message

  • 2
    Antoine

    Bonjour,

    J’ai essayé d’utiliser ce plugin pour générer un « catalogue » c’est à dire un pdf regroupant tous les articles d’une rubrique
    J’ai donc mis dans mon rubrique.html

    [<a href="[(#URL_PAGE{spipdf}
                                |parametre_url{spipdf,spipdf_catalogue}
                                |parametre_url{id_rubrique,#ID_RUBRIQUE}
                                |parametre_url{nom_fichier,rubrique_#ID_RUBRIQUE})]">
                                télécharger le catalogue de cette rubrique format PDF</a>]

    J’ai ensuite copié simplement spipdf_article.html du plugin dans mon répertoire squelettes et modifié la première ligne (la boucle principale)
    <BOUCLE_principale(ARTICLES) {id_rubrique} {par date}{inverse}>
    ET ça marche, mais pas à tout les coups. pour une rubrique qui contient entre 1 et 6/7 articles : ok
    Mais pour les « grosses » rubrique le pdf généré fait une page, qui est blanche.
    Auriez vous le commencement de début d’une idée quelconque ?
    Cordialement

    • Yves Tannier

      Bonjour,

      Le problème peut venir de certaines expressions régulières de la fonction spipdf_nettoyer_html du fichier spipdf.php

      Essayez de commenter la ligne 239 du fichier spipdf.php

      $html = spipdf_nettoyer_html($html,$possible_librairies[$librairie_pdf]) ;

    • Antoine

      Je vous remercie !
      Entre temps, en relisant un peu plus attentivement tous les messages de ce forum, j’ai tenté de simplifier mon fichier spipdf_catalogue.html et cela fonctionne.

      <BOUCLE_principale(ARTICLES) {id_rubrique}>
        [(#LOGO_SITE_SPIP)<br />]
         <div id="hierarchie"> .............</div>
        [(#LOGO_ARTICLE)]
        [<h1>(#TITRE|supprimer_numero)</h1>]
        [<div class="chapo_simple">(#CHAPO)</div>]
        [(#TEXTE|abs_url)]
        <formfeed />
</BOUCLE_principale>

      Le rendu est simple, mais comme tous les articles sont « formatés » avec des règles assez strictes, cela fonctionne parfaitement.

      J’en conclu bêtement que le fait d’avoir simplement supprimé les |image_reduire du squelette a résolu mon problème ...
       ?
      Cordialement

    Répondre à ce message

  • 2
    bruno31

    Qui a essayé les dernières versions des librairies ?

    En début d’année 2012, j’avais essayé les 3 librairies et j’en étais arrivé à la conclusion que c’était mPDF la plus aboutie.

    En regardant le forum de mPDF, je vois que l’auteur a arrêté le développement et que la dernière version est la 5.5. Je ne l’ai pas encore essayé

    A l’époque, j’avais regardé du côté de HTML2PDF mais elle était beaucoup moins avancée que mPDF. Mais la librairie a peut-être évolué depuis ? Qqun a t’il testé ?

    • Yves Tannier

      Bonjour,

      Je n’ai pas encore testé les nouvelles version de HTML2PDF. L’aspect le plus bliquant était la gestion des images « float ». A voir....

    • bruno31

      J’ai fait qq test. Apparemment pas de grosses évolutions.

    Répondre à ce message

  • 7
    alquitte

    Bonjour,

    je teste pour la première fois ce plugin : je rencontre deux soucis :
    -  sur les articles très longs, la génération du pdf produit une page blanche >> pb d’articles longs que tu évoques Yves sur ton post du 19 avril
    -  les images « img » ou les « doc » ne s’affichent pas du tout (mais les logos si !)

    j’utilise SPIP 2.10 et la librairie mpdf

    > pour les articles très longs, je ne peux pas y changer grand chose >> c’est un site de syndicat,
    > pour le souci sur les images, j’ai essayé les propositions dans les commentaires : commenter certaines lignes du fichier php, mais sans succès...

    pouvez-vous m’aider ou m’éclairer ?

    merci d’avance !

    • Yves Tannier

      Bonjour,

      Concernant les articles long, il s’agit également d’un problème avec une expression régulière. Peux-tu essayer en supprimant la balise LESAUTEURS de spipdf_article.html ?

      Pour les img ou les doc, on ne m’a pas fait remonté de problème à ce niveau. Ca doit venir du chemin vers IMG. Tu as chargé le plugin en FTP ou via l’espace privé ?

      J’espère pouvoir corriger prochainement ces soucis (pas facile de trouver le temps)...

      ++ Yves

    • Bonjour,
      en supprimant la balise LESAUTEURS >> pas de changement sur les articles longs

      j’ai chargé le plugin en ftp
      dois-je essayer d’une autre manière via l’espace privé plutôt ?

      merci pour ta réponse

    • alquitte

      j’ai oublié de m’identifier sur le précédent commentaire,
      je viens d’essayer le plugin en installation auto via l’espace privé : même souci pour les images !

      cordialement

    • Yves Tannier

      Bonjour,

      Autant pour les articles longs on m’a signalé ce problème, autant pour les images, je ne vois pas trop d’où ça peux venir...

      Il faudrait d’appeler directement une image dans le squelette spipdf_article.html...

      Toujours pas eu le temps de me pencher sur le souci avec les articles longs...

    • Loiseau2nuit

      Bonjour :)

      Confronté au même prooblème ici, et pareillement, la suppressions de #LESAUTEURS n’a rien donné.

      Constaté ce jour sur un spip 2.1.10 SVN mutualisé avec plateforme complète à jour (spip + plugins)
      Je précise que je charge Spipdf par le dossier extensions. Est-ce que ca peut venir de là ?

      Par ailleurs, tu sembles suggérer qu’on t’avait déjà remonté l’info. As tu un lien vers les fils concernés s’il te plait ?

      Merci beaucoup en tout cas, pour le boulot abattu :)

    • Yves Tannier

      Le bug des articles longs devrait-être résolu

    • alquitte

      Hello,

      pour info
      vient de re-tester le plugin spiPDF au cours d’une maintenance avec plugin remis à jour, librairie mpdf à jour et version de spip (SPIP 2.1.19) aussi à jour, j’ai toujours un souci avec les articles longs ! (le pdf est vierge).

    Répondre à ce message

  • robomatix

    Bonjour,

    Hier, nous avons eu des problèmes sur la génération de pdf d’une revue de presse...
    Pour éviter le problème, nous avons du mettre ’en cours de rédaction’ certains article qui ne semblaient pas passer...

    Spip 2.1.10
    SpiPdf 0.2.1
    Lib : mpdf

    Voici le code de la boucle qui récupère les articles génant :

                <BOUCLE_rubrique_suite(RUBRIQUES){id_secteur=1}{id_rubrique !IN 109,2,114}{par num titre, titre} >
                <BOUCLE_jour_suite(ARTICLES) {id_rubrique}{agenda date, jour, (#ENV{date_revue_presse}|annee), (#ENV{date_revue_presse}|mois), (#ENV{date_revue_presse}|jour)} {par id_rubrique} {par date} {inverse}{statut=publie}>
                    <BOUCLE_rubrique_titre_suite(RUBRIQUES) {id_rubrique}>
                        [<h2>(#TITRE|unique)</h2>]
                    </BOUCLE_rubrique_titre_suite>
                    <h3>#TITRE</h3>
                    <div class="texte">
                        [(#TEXTE|image_reduire{800,0})]
                    </div>
                                                                                 [(#REM) Portfolio : album d'images ]
                            <B_documents_portfolio_suite>
                                <div id="documents_portfolio">
                                    <BOUCLE_documents_portfolio_suite(DOCUMENTS) {id_article} {mode=document}{extension IN png,jpg,gif} {par num titre, date}{doublons}{vu=non}>
                                        [(#FICHIER|image_reduire{0,800})]
                                </BOUCLE_documents_portfolio_suite>
                                </div><!-- #documents_portfolio -->
                            </B_documents_portfolio_suite>
                </BOUCLE_jour_suite>
            </BOUCLE_rubrique_suite>

    Ce matin, j’ai voulu tenter de régler le problème et ai donc fait une boucle comme celle-là dans un fichier de test pour récupérer les articles ’en cours de rédaction’ qui posaient problème :

                <BOUCLE_rubrique_suite(RUBRIQUES){id_secteur=1}{id_rubrique !IN 109,2,114}{par num titre, titre} >
                <BOUCLE_jour_suite(ARTICLES) {id_rubrique}{agenda date, jour, (#ENV{date_revue_presse}|annee), (#ENV{date_revue_presse}|mois), (#ENV{date_revue_presse}|jour)} {par id_rubrique} {par date} {inverse}{statut=prepa}>
                    <BOUCLE_rubrique_titre_suite(RUBRIQUES) {id_rubrique}>
                        [<h2>(#TITRE|unique)</h2>]
                    </BOUCLE_rubrique_titre_suite>
                    <h3>#TITRE</h3>
                    <div class="texte">
                        [(#TEXTE|image_reduire{800,0})]
                    </div>
                                                                                 [(#REM) Portfolio : album d'images ]
                            <B_documents_portfolio_suite>
                                <div id="documents_portfolio">
                                    <BOUCLE_documents_portfolio_suite(DOCUMENTS) {id_article} {mode=document}{extension IN png,jpg,gif} {par num titre, date}{doublons}{vu=non}>
                                        [(#FICHIER|image_reduire{0,800})]
                                </BOUCLE_documents_portfolio_suite>
                                </div><!-- #documents_portfolio -->
                            </B_documents_portfolio_suite>
                </BOUCLE_jour_suite>
            </BOUCLE_rubrique_suite>

    Et là, pas de problème, le pdf était bien généré avec uniquement les articles qui posaient problème...

    J’avoue ne pas trop comprendre... Est ce que quelqu’un aurait une idée ?

    Répondre à ce message

  • 2
    yohannp

    Hello,
    Apparemment, pas possible de définir des header et footer pour le PDF en squelette SPIP :/ ? Quelqu’un a un exemple ?

    Répondre à ce message

  • 2
    Didier

    Bonjour

    Petit curiosité je viens d’essayer d’installer le plugin ..je suis chez free, j’ai SPIP 2.17 et l’installation ne fonctionne pas, j’obtiens :

    Impossible d’activer le plugin ../plugins/auto/spipdf

    Nécessite SPIP en version [2.0.0 ;3.0.*] minimum.

    Curieux !!

    • Globy

      J’ai le même problème et message sur 2.17...
      Nécessite SPIP en version [2.0.0 ;3.0.*] minimum ??

    • Yves Tannier

      Bonjour,

      Effectivement, c’est curieux. Je pense qu’il faut remplacer 2.0.0 par 2.* dans plugin.xml

      Pouvez-vous essayer ?

    Répondre à ce message

  • 7
    bruno31

    Yves

    Peux-tu me confirmer que les paramètres de la balise <page> dans le squelette ne sont pas exploitées ? sauf la lib.

    Si oui, pourquoi ?

    • bruno31

      En tous cas, c’est confirmé par le code de spipdf.php.

      Pour prendre en compte les paramètres de la balise page, j’ai remplacé la ligne 258 par :

      $format_page = $GLOBALS['valeurs_page']['format']; $backtop = $GLOBALS['valeurs_page']['backtop']; $backbottom = $GLOBALS['valeurs_page']['backbottom']; $backleft = $GLOBALS['valeurs_page']['backleft']; $backright = $GLOBALS['valeurs_page']['backright'];  $margin_header = $GLOBALS['valeurs_page']['margin_header']; $margin_footer = $GLOBALS['valeurs_page']['margin_footer'];

      et la ligne 274 par :

      $mpdf = new mPDF(SPIPDF_CHARSET, $format_page, 0, "", $backleft, $backright, $backtop, $backbottom, $margin_header, $margin_footer);

      A intégrer peut-être dans une prochaine mise à jour du plugin ?

    • Yves Tannier

      Il faut que je regarde plus spécifiquement mais j’avais normalement prévu le coup avec le array $possible_librairies ligne 203.

      Il doit falloir mettre ’traite_balise_page’ => false pour mpdf pour ne pas que ça passe par la fonction traite_balise_page qui supprime effectivement la balise page avant l’instanciation de la classe de génération de PDF.

      Si ça fonctionne, je changerais pour que ’traite_balise_page’ soit sur false par défaut.

    • bruno31

      Yves

      En tous cas, avec les modifs que j’ai faites (message plus haut), cela marche impeccable. Et je peux régler toutes les marges comme je veux.

      A l’analyse du code, il m’a semblé comprendre qu’il s’agissait d’un oubli. Alors que le constructeur de la classe mPDF peut prendre en compte ces paramètres de marge.

    • Yves Tannier

      As tu essayer la modification que je t’ai indiqué ?

    • Je viens t’essayer ta proposition de modif mais cela ne marche pas.

      Normal, puisque dans la ligne 274, il manque les paramètres de marges dans le construction de classe mPDF.

    • Yves Tannier

      Je pensais qu’il n’était pas nécessaire de passer les paramètres au constructeur mpdf s’ils étaient présent dans la balise page. C’est peut-être avec HTML2PDF que ça fonctionne ainsi.

      Je modifierais mon code

    • yohannp

      J’ai intégré les modifications ici : http://zone.spip.org/trac/spip-zone/changeset/65392

      C’est ok pour l’auteur ?

    Répondre à ce message

  • alexandre

    Bonjour,

    J’ai déjà utilisé ce plugin à plusieurs reprises mais désormais je rencontre un problème avec les images.

    C’est par contre la première fois que je teste sous SPIP3.
    J’utilise mpdf.

    Dans le pdf, les images sont remplacées par quelque chose dans ce gout là :

    %PDF-1.4 % 3 0 obj <> /Annots [ 5 0 R ] /Contents 4 0 R>> endobj 4 0 obj <> stream
    x=1 @P O1’Xˢ « tu »QpO#䃡’a > endobj 1 0 obj <> endobj 6 0 obj <> endobj 7 0 obj < /Length
    50>> stream cPΠ!Q ) Bc E jfD3 8\ ) endstream endobj 8 0 obj < /Length 156>> stream
    (c` (rɮ7/« Lh 8, .ˆȻ Vݖ ,c &Ru ?| efŦ ?kpͩ ?e( Ki ןsI/ KX »aeZV$h K Eh endstream
    endobj 2 0 obj <> /ExtGState <> /XObject <> >> endobj 9 0 obj <> endobj 10 0 obj <> endobj xref
    0 11 0000000000 65535 f 0000000774 00000 n 0000001619 00000 n 0000000015 00000 n
    0000000242 00000 n 0000000410 00000 n 0000000863 00000 n 0000000924 00000 n 0000001212
    00000 n 0000001760 00000 n 0000001883 00000 n trailer <> startxref 1993 %%EOF

    Est-ce déjà arrivé à quelqu’un ?

    Les images proviennent du champ texte, j’ai essayé plusieurs formes :

    #TEXTE
    [(#TEXTE|image_reduire500,0)]
    [(#TEXTE|abs_url|image_reduire500,0)]

    Une idée ? Une piste ?

    Répondre à ce message

  • 1
    paolo

    Jusqu’à maintenant j’ai obtenu les meilleurs résultats avec tcpdf. Y a-t-il le project d’inclure ce système aussi, ou est-ce trop grand ?

    • Yves Tannier

      Bonjour,

      tcpdf ne génére pas de PDF à partir de HTML. Ce qui est le cas pour les librariries mpdf, html2pdf et dompdf, utilisées par le plugin. Certaines d’ailleurs reposent sur tcpdf (html2pdf et mpdf).

    Répondre à ce message

  • robomatix

    Bonjour !

    Avec le code :

    <h3>#TITRE</h3>
                    <div class="texte">
                        [(#TEXTE|image_reduire{800,0})]
                    </div>
                                                                                 [(#REM) Portfolio : album d'images ]
                            <B_documents_portfolio_suite>
                                <div id="documents_portfolio">
                                    <BOUCLE_documents_portfolio_suite(DOCUMENTS) {id_article} {mode=document}{extension IN png,jpg,gif} {par num titre, date}{doublons}{vu=non}>
                                        [(#FICHIER|image_reduire{0,800})]
                                </BOUCLE_documents_portfolio_suite>
                                </div><!-- #documents_portfolio -->
                            </B_documents_portfolio_suite>

    Le pdf est vide lorsqu’il y a une image dans le texte. Par contre, les images du portofolio, lorsqu’il y en a ne posent pas de problème... Avant un passage à php 5.3.3, il me semble qu’il n’y avait pas de problème... Pour info SPIP 2.1.10. Librairie mpdf

    Est ce que d’autre ont le même problème ?
    Une piste pour le résoudre ?
    Merci !.

    Répondre à ce message

  • 2
    dreline

    Je suis en train de migrer mon site vers la SPIP 3.0, je tiens à signaler qu’à première vue, spipdf 0.2 fonctionne parfaitement avec. J’ai généré quelques PDF sans soucis.

    • FdM

      Ca m’intéresse beaucoup, car à première vue chez moi, non.

      Des tuyaux ?

    • dreline

      Je viens de regarder encore, et je n’ai détecté aucun soucis.

      J’ai fais la mise à jour dans le répertoire de la version 2.1.14 qui avait déjà je plugin activé, puis j’ai juste réactivé le plugin.

    Répondre à ce message

  • bruno31

    JAVASCRIPT dans le squelette :

    Bonjour

    J’ai un squelette spécifique pour générer mon PDF.
    Si j’insère du JAVASCRIPT dans ce squelette, est-ce que le résultat affiché sera pris en compte par le générateur de PDF ?

    Répondre à ce message

  • 3
    bruno31

    Conseil pour la mise en page avec mPDF :

    La gestion des FLOAT et des div imbriquées est des plus approximative. Pourtant c’est mPDF qui s’en sort le mieux.

    Idem pour les background et les border.

    Faire une mise en page, même simple devient un exercice très difficile voir impossible.

    Alors, le mieux est de tout faire avec des tableaux. Là, on arrive à positionner des blocs assez correctement.

    • Yves Tannier

      Bonjour,

      Il est difficile de trouver une classe PDF qui fait tout correctement. Il faut cibler selon les usages.

      Il faut en effet s’orienter vers une mise en page très basique HTML 4 pour un rendu correct.

    • bruno31

      Un autre conseil : si vous rencontrez des problèmes de mise en page des images, essayez tout d’abord de neutraliser la fonction spipdf_nettoyer_html présente dans spippdf.php du plugin.

      Il suffit de mettre au début de la fonction un :
      return $html;
      Ensuite vous déplacez progressivement cette ligne dans la fonction pour activer les traitements de filtrage au fur et à mesure.

      Yves a codé cette fonction pour ces propres besoins et certains traitements ne vous conviendront peut-être pas ?
      Par exemple, les titres et descriptions d’image sont systématiquement supprimées.

      De plus, certains traitements visent à palier une insuffisance dans les librairies. Mais comme les librairies évoluent, il se peut que les traitements deviennent inutiles, voir contre-productifs.

    • Yves Tannier

      Dès que j’ai un peu de temps, je coderais quelques choses de plus modulaire

      Merci pour tes retours.

    Répondre à ce message

  • 8
    livier

    Après mes petits problèmes de mise en forme de la version 0.1, je viens voir ce que donne la version 0.2 ...

    Je retombe sur les mêmes défauts, alors que je n’ai même pas installé les librairies... j’ai l’impression d’un cache qui reviens. Peux tu nous dire ou se cache le fichier pdf généré pour que je puisse le supprimer et refaire des essais propres en testant les 3 librairies.

    Pour l’install des librairies : /spip/plugins/lib/ est il un endroit correct ou il vaut mieux /spip/lib ou encore /spip/plugins/spipdf/lib. Je préfèrerais le premier si cela ne pose pas de problème (passera mieux dans ma sauvegarde).

    • Yves Tannier

      Bonjour,

      Les fichiers PDF sont mis en cache de la même façon que les fichiers HTML ; dans le cache de SPIP.

      Mais il est vrai que je n’avais pas pensé à une chose : il n’y a pas de bouton « recalculer le PDF » ;)

      Donc en attendant mieux, plusieurs possibilités :

      • ajouter la balise cache dans spipdf_article.html (pas testé mais ça devrait fonctionner en théorie) 
        #CACHE{0}
      • vider le cache général de spip
      • ajouter &var_mode=calcul sur le lien de génération du PDF

      Pas d’autre solutions à proposer actuellement mais je vais y réfléchir.

    • livier

      Je viens de perdre un long post d’explication de retour d’expérience ... M....
      Je reprend caaalmement et un peu plus court !

      Sur les 3 endroits que j’avais évoqué pour placer les librairies, seul /spip/lib semble fonctionner. Les deux autres emplacements me renvoient au lieu du fichier pdf, le message suivant :

      Impossible de trouver la librairie de génération de PDF mpdf. vérifiez que vous l’avez bien téléchargée et installée dans /lib

      En plaçant mes librairies ainsi : /spip/lib/mpdf j’obtiens l’ouverture d’un fichier pdf ... mais c’est une page blanche.

      Je suis en spip mutualisé et les droits sur les répertoires de librairie sont : admin.www-data 755 . Y a t’il là une partie de la difficulté ?

    • Yves Tannier

      La librairie dans le répertoire /plugins/spipdf/lib/mpdf devrait en théorie fonctionner puisque je teste sur /lib et sur /plugins/spipdf/lib/mpdf

      Concernant la page blanche, on ne m’a encore pas remonté ce type de bug alors là je ne vois pas. Essaye en utilisant une autre librairie (HTML2PDF par exemple).

      Merci de préciser la version de PHP et le système d’exploitation de test.

    • livier

      Pour répondre à ta question sur les versions utilisée :
      Mon seveur en ligne est une part de chez Gandi.
      Sur mon serveur en ligne
      Phpinfo me renvoie :
      ** PHP Version 5.2.4-2ubuntu5.12
      Linux gandiaxe2 2.6.18-xenU #1 SMP Tue Nov 24 18:35:42 CET 2009 i686 **
      Cela répond il à ta question ou tu veux que je te renvoies des détails ?

      Sur mon serveur local :
      **PHP Version 5.3.2-1ubuntu4.7
      Linux montreal1 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 **

      Je continue de tomber sur des sorties pdf avec une page vide, à partir de mon serveur en ligne.

      Par contre sur mon serveur local j’obtiens des pdf qui ont les mêmes défauts qu’avec la première version du plugin (librairrie html2pdf) . J’essaye une autre librairie, pour voir, mais le pdf reste identique. Je pousse le bouchon en cherchant l’erreur :

      <page lib_pdf="paspdf" orientation="P" format="letter" backtop="7mm" backbottom="7mm" backleft="10mm" backright="10mm">

      Me renvoie encore le même pdf, cela ne devrait pas !
      J’ai l’impression que vider le cache ne suffit pas !?!

    • Yves Tannier

      Vider le cache suffit ;)

      Quand je fais mes tests, j’ajoute &var_mode=calcul sur mes liens de génération et ça fonctionne.

      Concernant la page blanche, je ne vois pas. As-tu essayé avec une autre lib ? Est-ce que ton serveur de prod affiche les erreurs d’exécution de PHP ?

      Quels sont les défauts que tu rencontres avec les PDFs ?

    • Thomas Weiss

      Bonjour. je viens d’installer ce plugin et je l’ai essayé avec les 3 librairies. Cela fonctionne très bien pour les petits document mais pour un document qui est censé faire 57 pages : page blanche. Le bug semble déjà connu. Cordialement.

    • Thomas Weiss

      précisions la version mpdf est 5.4 (15/2/12)

    • Yves Tannier

      Bonjour,

      Oui, ce bug est récurrent. Pouvez-vous m’envoyer le contenu de cet article que je fasse des tests dès que possible (yvestan chez gmail)

    Répondre à ce message

  • 2
    dreline

    Bonjour,

    J’ai eu le bug des pdf vides sur l’ URL ci-dessous, j’ai corrigé en mettant à jour à la dernière version 56015, mais comme c’était insuffisant j’ai commenté les appels à preg_replace_callback, l’un après l’autre. Celui qui a fonctionné est celui de la ligne 105 : // supprimer les spans autour des images et récupérer le placement

    URL :
    http://www.sden.org/polaris/aides-de-jeu-25/lieux-et-decors/article/les-etablissements-de-loisirs

    • Yves Tannier

      Merci pour ce retour, je vais regarder ce qui pose problème dans ces expressions régulières. Quelle version de SPIP utilise tu ?

    • dreline

      C’est la version SPIP 2.1.11

    Répondre à ce message

  • dreline

    C’est la version SPIP 2.1.11

    Répondre à ce message

  • 3
    Alexandra

    Bonjour Yves, ce plugin fonctionne t-il en SPIP 3 ? L’as tu essayé ? ou d’autres ? des retours ? merci beaucoup et bonne journée

    • Yves Tannier

      Bonjour Alexandra,

      Non, je n’ai pas essayé. J’essaierais ça prochainement... Tiens moi au courant de son fonctionnement (ou non) si tu essayes de ton côté.

      Bonne journée

    • Alexandra

      Bonjour Yves,
      Je viens d’installer le plugin sur une svn de branche stable en version 2.
      Mon MAMP était à 32 mo de memory limite dans php.ini et ca ne lui a pas plus. J’ai du lui allouer 100 mo pour être tranquile, mais peut être que moins de mémoire est possible.
      Cette nouvelle librairie est-elle bien plus gourmande que celle de la version V1 ?
      Quelle valeur tu mets toi en memory limite ? Je ne suis pas sure d’avoir la main sur le php.ini du futur serveur de prod. Je vais peut être revenir à une version antérieur ? des retours à ce sujet ? Merci
      ps : on me glisse dans l’oreillette que 32 c’était de toute façon pas beaucoup et qu’on peut mettre 128mo facile sur de la prod.

    • Yves Tannier

      Alexandra, merci pour ton retour.

      Effectivement, 32 Mo ce n’est pas énorme pour des librairies de génération de PDF ou des scripts des génération d’images qui utilisent l’extension GD de PHP par exemple.

      Mon plugin en tant que tel ne consomme pas beaucoup de mémoire. Ce sont bel et bien les librairies de génération de PDF depuis le HTML qui demande de la ressource machine.

      Je ne peux pas te donner de chiffre précis car je n’ai pas les même memory_limit selon les machines et les applications mais effectivement, tu peux directement passer à 128 Mo pour ton MAMP. Et ton serveur de production devrait bien avoir au moins 128 Mo ;)

    Répondre à ce message

  • 2
    bruno31

    mPDF trop buggué :

    Ce message juste pour dire que le support CSS de mPDF est plus qu’approximatif.

    Je tente de faire des mises en page, pourtant simples, et je galère. Par exemple, afficher du texte dans une DIV avec une certaine taille et une couleur de fond. Et bien c’est presque impossible.

    Je découvre des tas de bugs, tous plus bizarres les uns que les autres. Certaines limitations sont connues et documentées. Mais il y en a beaucoup d’autres en réalité.

    Plus grave, il y a un forum sur le site mais l’auteur de la librairie est aux abonnés absents. Et quand on lit ses anciennes réponses, on sent bien qu’il a fait la librairie pour ses besoins personnels et qu’il n’a pas l’intention de la maintenir.
    Je ne lui jette pas la pierre. Il est déjà bien gentil de la donner gratuitement. Mais je constate c’est tout.

    Est-ce que les autres librairies sont maintenues ?
    domPDF par exemple ?

    • bruno31

      Je viens d’essayer dompdf :
      -  la dernière version prendrait partiellement en charge le FLOAT. Mais l’activation de l’option provoque un plantage PHP chez moi.
      -  problème d’affichage en UTF-8
      -  La fonction de génération de la table des matières n’existe pas
      -  je n’ai pas trouvé l’info sur la gestion des entêtes et pied-de-page bien que cela semble possible de le faire

      Je n’ai pas essayé HTML2PDF mais la lecture du wiki m’a suffit :
      -  pas de table des matières
      -  pas de header et footer
      -  doc très sommaire

    • Yves Tannier

      dompdf est maintenu et le mainteneur fait des efforts pour gérer correctement le float mais ce n’est pas une mince affaire

      Il me semble que HTML2PDF est également bien suivi sur son forum.

      mPDF est un mix de HTML2PDF et FPDF

    Répondre à ce message

  • 1
    bruno31

    mPDF : comment obtenir des Footers différents sur page paire et impaire :

    Je n’arrivais pas à obtenir des pieds de page différents sur les pages paires et impaires.
    Sur toutes les pages, j’avais le footer défini en « ODD »

    Je me suis arraché les cheveux pendant des heures avant de trouver la solution :
    Il faut modifier spipdf.php et ajouter après le constructeur mPDF à la ligne 276 :
    $mpdf->mirrorMargins = true;

    L’explication est donnée ici : http://www.mpdf1.com/mpdf/forum/com...

    Répondre à ce message

  • 6
    bruno31

    Problème d’affichage de vignette

    Bonjour,
    je rencontre une différence d’affichage sur les vignettes :
    -  Dans le HTML, les vignettes comportent bien une bordure, avec le titre de l’image
    -  Dans le PDF, pas de bordure ni de titre

    Je précise qu’il s’agit bien du HTML généré avec le squelette spip_article.html
    que je visualise pour le débuguage avec l’url : http://monsite/spip.php?page=spipdf_article&id_article=11&nom_fichier=article_11&var_mode=recalcul

    Yves, as-tu une idée ou une piste d’investigation à me proposer ?

    • Yves Tannier

      Je ne comprends pas ta remarque concernant les bordures et les titres. S’agit-il d’images placées avec  ? avec  ?

      Il faut noter que les classes de génération de PDF à partir de HTML ont du mal avec le positionnement d’élément flottant (float). C’est mPDF si s’en sort le mieux. J’ai donc parfois du faire des compromis et virer ou remplacer via des expressions régulières certains codes de spip.

    • bruno31

      Dans la CSS de l’image, j’ai mis une bordure (border) avec un espace de qq pixel (padding).
      Je suis étonné que cette caractéristique importante et standard ne soit pas prise en compte par mPDF ?

      Il s’agit du titre qui est affiché sous l’image, avec une éventuelle description.

    • bruno31

      Yves

      Je pense avoir compris. Dans le code du plugin, il y a un preg_replace qui supprime le ’dl’ autour des images. Je pense qu’il supprime aussi les styles spip_document*

      C’est dommage de ne pas pouvoir hériter des styles de habillage.css pour les images.

    • bruno31

      On contourne le pb en ré-insérant les propriétés CSS dans les styles pdf_img_float_* du squelette

      Mais on perd l’héritage. En cas de modif sur la CSS du site, il n’y a pas transfert sur la CSS du pdf.
      Dans le code, il doit être possible de récupérer les styles autour du ’dl’ et de les conserver ?

    • Yves Tannier

      J’ai du faire certain compromis en fonction des possibilités offertes pas par les librairies. Pour mon usage ça suffisait ;)

      Les dl/dt n’était, si je me souviens bien, pas géré par HTML2PDF que j’utilisais comme seule librairie sur la première version du plugin.

      Le plus simple est de commenter les différentes fonctions de remplacement que j’ai intégré et voir ce que ça donne (remplaceDt, remplaceDl, remplaceCenter etc...)

      Tiens moi au courant des tes essais.

    • Yves Tannier

      Tu l’avais sans doute compris : la fonction qui traite le code généré par SPIP avant de l’envoyer dans les librairies est spipdf_nettoyer_html. Elle essaye de palier aux incompatibilités entre le code SPIP et les librairies HTML vers PDF.

    Répondre à ce message

  • 1
    bruno31

    Bonjour

    Je compte utiliser ce plugin pour générer des docs de grandes dimensions.

    Je souhaite utiliser la structuration de SPIP ; c.a.d rubrique, sous-rubriques, articles.
    Donc dans le lien de génération du PDF, le paramètre sera un n° de rubrique, et le squelette se chargera d’incorporer toutes les sous-rubriques et articles.
    Évidemment, je devrais créer un squelette spécifique pour cela.

    En lisant les commentaires, je suis un peu inquiet avec les problèmes de pages blanches.
    Alors, est-ce que le plugin est capable de générer des docs de très grandes dimensions ?

    MERCI

    • Yves Tannier

      Bonjour,

      Si vous rencontrez le problème de la page blanche, revenez vers moi avec un exemple de contenu généré et j’essairais de débuger ce souci.

    Répondre à ce message

  • 3
    Mickael

    Bonjour,

    Je suis sou spip 2.1.2 et j’ai un soucis pour la generation de pdf au format paysage.

    J’ai beau mettre orientation=« L » impossible d’avoir un pdf au format paysage (mpdf)

    Avez une idée a me soumettre pour corriger ce problème ?

    Merci d’avance

    Répondre à ce message

  • 2
    marjorie

    Plugin génial, ça marche bien, facilement, ça se paramètre bien... seulement dès qu’il y a une boucle avec beaucoup de résultats... page blanche. (même si on demande à la boucle de ne reporter qu’un titre par exemple... pour moi au dessus de 20 résultats pour une boucle, j’ai une page blanche).

    Il semblerait que je ne sois pas la seule à souffrir de ce problème de page blanche quand la page est « trop lourde », j’ai épluché le forum de cet article et j’ai essayé de chercher dans la doc de mpdf, mais je n’ai pas résolu mon souci. Si quelqu’un a trouvé... merci de m’expliquer !

    • Yves Tannier

      [copie de ma réponse sur l’article archive]

      Bonjour,

      Le problème vient sans doute des expressions régulières que j’utilise pour nettoyer le code SPIP. Il faut les commenter une par une et voir le résultat.

      dans la fonction spidf_nettoyer_html, il faut commenter les lignes $html = preg_replace_callback en mettant 2 slash devant et voir ce que ça donne.

      Attention à bien avoir var_mode=calcul dans l’URL qui appelle le PDF.

      J’essayerais de regarder mais ce n’est pas facile à tester. Il s’agit d’une boucle sur des articles ?

    • marjorie

      le problème était le même pour une boucle sur un article, ou sur une rubrique....

      Je vais tester cette solution.

      Merci beaucoup pour ce début d’aide !

    Répondre à ce message

  • 1
    kYOmii

    Bonjour,

    J’ai un souci lors de la génération du pdf (sous IE 6 que je suis obligé d’utiliser)
    si je fais ouvrir le pdf (au lieu d’enregistrer) j’ai un message d’erreur « There was en error opennig this document. This file cannot be found »
    Connaissez vous une solution pour contourner ce problème ?

    Merci par avance

    Répondre à ce message

  • 7
    katmandou

    Bonjour,
    j’essaye d’utiliser votre plugin avec mpdf, et j’ai besoin d’appeler certaines fonctions de mpdf pour la mise en page, mais comment inclure cet appel dans mon code html ?

    j’ai essayé ça mais j’ai une erreur :

    <?php 		
include_spip('lib/mpdf/mpdf');
SetHTMLFooter("<div style='float:center'>My footer</div>");
?>

    Merci de votre aide.

    • Yves Tannier

      Ce n’est pas prévu avec ce plugin. Mais pouquoi ne pas ajouter le footer directement dans le squelette qui sert de base à la génération du PDF ?

      Sinon, il faut jouer avec spipdf.php vers la ligne 269

      Yves

    • katmandou

      Aie, problème.
      Le footer doit être inséré dans chaque page A4, avec pagination.
      Je dois aussi faite des appels pour imposer un retour à la page suivante, à inclure quand je le souhaite dans mon code HTML.
      Sinon, je peux essayer d’utiliser directement mpdf sans plugin ?
      Merci quand même.

    • Yves Tannier

      Tu peux tout essayer :)

      Ceci étant, j’ai du mal à saisir ce qui te pose problème. Avec mpdf, tu peux ajouter un certain nombre de paramètres dans le squelette html.

      A titre d’exemple, j’ai ajouté :

      <sethtmlpagefooter name="phname" page="ODD"></sethtmlpagefooter>
<htmlpagefooter name="phname">Test de Yves</htmlpagefooter>

      dans spipdf_article.html, après et j’ai un joli pied de page.

      Ceci est documenté : http://mpdf1.com/manual/index.php?tid=176

    • Merci, les footer et header marchent avec cette méthode, par contre le <pagebreak /> ne fonctionne pas du tout, et si je mets un <tocpagebreak />, il me rajoute une page vide !
      J’utilise la dernière version 5.3 de mpdf.

    • katmandou

      Re-bonjour,
      j’ai essayé en utilisant <pagebreak /> directement dans le code mpdf (donc sans utiliser spipdf, et ça marche.
      Je suppose donc que spipdf filtre ce code qui m’est indispensable pour aller à la page suivante (je dois créer un manuel complet en pdf).
      Je ne vois pas dans spipdf.php comment enlever ce ’nettoyage’.
      Merci beaucoup de votre aide.

    • katmandou

      Bon,
      j’ai trouvé la cause du problème... et la solution !
      Dans le fichier spipdf.php lignes 165 et 177 faut remplacer « page » par « page » (rajouter un espace après page), car sinon il vire tous les tags qui commencent par page (donc pagebreak aussi).

    • Yves Tannier

      Bonjour,

      OK, je penserais à ajouter l’espace ;)

    Répondre à ce message

  • 1
    DD

    Bonjour,

    ce plugin me plait pour pouvoir générer des pdf avec le contenu d’un article + du contenu annexe mais j’ai 2 problèmes.. voici mon lien :

    [<a href="[(#URL_PAGE{spipdf}
	|parametre_url{spipdf,spipdf_article}
	|parametre_url{id_article,#ID_ARTICLE}
	|parametre_url{document,article_#ID_ARTICLE})]">
télécharger l'article au format PDF</a>]

    ce qui donne l’URL pour les article : spip.php ?page=spipdf&spipdf=spipdf_article&document=article_

    donc il me manque l’ID de l’article. Que dois-je changer ?

    mon lien est dans le pied de page : lorsque je l’entoure de

    <BOUCLE_artpdf(ARTICLES){id_article}>
...
</BOUCLE_artpdf>

    il disparaît (sur une page article) et si je ne l’entoure pas il apparaît sur toutes les pages du site.

    merci

    • DD

      Bonjour,

      C’était de ma faute, j’avais oublié id_article dans l’appel au modèle.

      j’ai un autre problème mais je ne sais pas si cela peut être résolu : j’ai des cartes Google insérées en iframe dans mes articles et elles ne s’impriment pas.
      Par contre si j’utilise la fonction « imprimer » du navigateur elles le sont (imprimées.)

      dd

    Répondre à ce message

  • 2
    audwill

    oups, j’avais posté sur le forum de la V0.1 du plugin. je re-poste donc ici, désolée.

    Je suis en train de tester le plugin sur un site en local (mamp, php5, spip 2.1.10, plugin 0.2.1 [44725]). ça marche globalement sur tous les articles, sauf sur les articles dans lequel le rédacteur a rentré deux images à la suite dans le champ texte, par exemple :

        <emb349|center>
    <emb350|center>

    Dans ce cas le pdf est vide, blanc. Si j’enlève l’une des deux images, le pdf s’affiche bien. Comment faire pour régler le pb ?

    merci !

    • Yves Tannier

      Bonsoir,

      Ca doit-être une des expressions régulières qui merdouille. Je vais regarde ça...

      En attendant, si tu connais un peu le PHP, tu peux commenter une par une les expressions de la fonction spipdf_nettoyer_html dans spipdf.php (les lignes qui commencent par $html = preg_replace...)

    • audwill

      merci pour ta réponse,

      j’ai commenté les expressions une par une et ce sont ces deux-là qui semblent poser problème :

      	$html = preg_replace_callback($patterns_float, 'remplaceDt', $html);

	$html = preg_replace_callback($patterns_puce, 'remplaceFloatPuce', $html);

      (lignes 120 et 130 du fichier spipdf.php)

      En les commentant, le pdf n’est plus blanc. (par contre, et ça doit être logique j’imagine, les float des images ne sont plus pris en compte dans le pdf produit).

    Répondre à ce message

  • 4
    escurel

    Bonjour Yves,
    Je pense qu’il y a un bug avec spipdf 0.2.1 rev 44725 et spip 2.1.10, 2.1.9, ......
    cette version modifie le traitement de la puce graphique de spip, si je saisie le raccourcis typo tiret - ça remplace l’image de la puce par une liste non ordonnée

    <ul class="spip">
	<li> puce graphique</li>
</ul>

    c’est peu être dans cette fonction de spipdf.php qu’il y a une collision entre le squelette de spipdf et celui de spip non ?

    // supprimer le puces graphiques (d'après le plugin couteau suisse)
function spipdf_pre_typo($texte) {
    return preg_replace('/^-\s*(?![-*#])/m', '-* ', $texte);
}

    cordialement

    • Yves Tannier

      Bonjour,

      Je vais regarder ça dès que j’ai 5 minutes. Il y a aussi un souci quand les articles sont très long. Ca vient de quelques expressions régulières.

      ++ Yves

    • phracktale

      Bonjour, je suis justement confronté au problème.
      Des pistes pour la résolution ?

    • Yves Tannier

      Bonjour,

      Je ne sais plus pour quelle raison j’avais activé le remplacement des puces de spip... je crois que ça posait un pb mais impossible de me souvenir duquel ;)

      En attendant mieux, il suffit de commenter dans spipdf.php :

      // supprimer le puces graphiques (d'après le plugin couteau suisse)
 function spipdf_pre_typo($texte) {
        // return preg_replace('/^-\s*(?![-*#])/m', '-* ', $texte);
return $texte;
}
    • phracktale

      Bonjour,
      Mon problème n’était pas celui-là, j’ai commenté ces 2 filtres pour avoir une génération correcte.

      // replacer id par name pour les notes
      $patterns_note = ’//iUms’ ;
      function remplaceIdParName($matches) return str_replace(’id=\’’, ’name=\’’, $matches[0]) ;
      //$html = preg_replace_callback($patterns_note, ’remplaceIdParName’, $html) ;

      // float sur les puces graphiques
      $patterns_puce = ’//iUms’ ;
      function remplaceFloatPuce($matches) return str_replace(’style=\’’, ’style=\’float:left ;’, $matches[0]) ;
      //$html = preg_replace_callback($patterns_puce, ’remplaceFloatPuce’, $html) ;

    Répondre à ce message

  • 2
    Yves Tannier

    (en réponse à un message de yonnel posté sur le forum de la version précédente)

    Je poste ici car je pense que vous utilisez la version 0.2.0 du plugin...

    Merci pour votre retour. A vrai dire, je n’ai pas tout compris à votre problème... Vous voulez dire qu’aucune feuille de style ne fonctionne chez vous sans cette modification ?

    Parce que quand je teste une feuille de style personnalisée (exemple : auteur.css dans squelettes-dist), de mon côté ça fonctionne.

    Dans ce cas, pouvez-vous me préciser votre configuration (Linux, Windows, Mac ? PHP4, PHP5 ?) ? Merci.

    • YONNEL

      Bonjour,

      Je suis sous windows VISTA, en appli locale sous XAMPP, PHP Version 5.3.1
      Je teste avant de livrer mon appli sur un serveur sous LINUX

      Rien ne fonctionnait sans cela chez moi.
      J’ai même été obligé de faire la même chose pour les images en background en ligne 20256 :
         $CSSstr = str_replace('localhost','127.0.0.1',$CSSstr);

      Malgré tout, alors que cela ne bloque plus, certaines images en background, style :
      #ColContenu .tabbox .contenu .inner ul.liste-mail { background: #FFF url(../images/picto_liste_mail.jpg) no-repeat top center; width:385px; padding:10px 0 5px 35px; margin:0;}
      n’apparaissent pas, alors que $this->cacasadeCSS en ligne 20356 fait bien apparaître l’image :

       [UL>>CLASS>>LISTE-MAIL] => Array
([BACKGROUND-COLOR] => #fff
 [BACKGROUND-IMAGE] => http://127.0.0.1/smart_afe/trunk/site/squelettes/images/picto_liste_mail.jpg

      Mais est-ce lié au pdf ?

      yonnel

    • Yves Tannier

      Est-ce que le pb se pose sous Vista et sous Linux ?

      Je vais tester dès que possible les backgrounds...

    Répondre à ce message

  • 1
    Fabien Ménager

    Bonjour, je suis le développeur le plus actif actuellement du projet dompdf (et je suis français).
    Je profite de cet article pour vous dire que si vous avez des questions sur cette bibliothèque, ou des suggestions, n’hésitez pas à m’en faire part, j’y répondrais avec plaisir.
    Suivez le projet sur Twitter pour être au courant des dernières nouveautés.
    Une remarque concernant le CSS float : je vais travailler sérieusement sur son support dans très peu de temps, et j’en parlerais pas tweet très certainement, ainsi que sur le tracker.

    • Yves Tannier

      Bonjour,

      Merci Fabien pour cette infos et pour le boulot sur dompdf. Je crois être déjà abonné au tracker concernant la gestion du float ;)

    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