Utilisation de FPDF

Bonjour à vous,

sur un site développé perso, j'utilise FPDF pour généré à la volée des PDFs et tout se passe bien.
La librairie est installée à la racine du répertoire ( comme conseillé sur leur site ) accompagnée de son dossier fonts et du script PHP qui me génère mon PDF de cette sorte:
<?php
require('fpdf.php');

// récupération de mes données, exemple:
	$civilite = $_SESSION['civilite'];
	$prenom = $_SESSION['prenom'];
	$nom = $_SESSION['nom'];
	$etc = $_SESSION['etc'];

// création de mon layout
class pdf extends FPDF {
	function Titre() { // Titre
		$this->SetXY(15,92);
		$this->SetFont('Arial','B',14);
		$this->Cell(183,5,'Mon titre',0,1,'C');
		$this->SetFont('Arial','',10);
	}
}

$pdf = new pdf();
$pdf->AddPage();
etc ...
?>
Je développement actuellement un plugin spécifique qui doit générer au final un PDF.

Et pour cette avant dernière phase, je galère ... c'est pourquoi je voulais savoir si quelqu'un a déjà utilisé cette librairie avec notre bête à Plume, et comment il s'en est sorti.

Dois-je mettre FPDF dans mon plugin ?
créer un autre plugin spécifique à FPDF ? ( ça serait mieux, peut-on appeler un plugin dans un plugin ? )
mettre FPDF à la racine du site ?
y-a-t-il des choses particulière à faire avec cette nouvelle class ?

Il faudrait que FPDF se génère indépendamment de PluXml, enfin je crois, comment s'y prendre ?
Est-ce que FPDF est la bonne solution ?

Que de questions ... Merci de votre aide.

Cordialement,
_____
D.San

Réponses

  • StéphaneStéphane Member, Former PluXml Project Manager
    Salut Daniel

    Et en ajoutant tout simplement au début du fichier de ton plugin la ligne suivante, ça n'irait pas ?
    require('fpdf.php');
    

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • Salut Stéphane,

    merci pour ta réponse.

    j'ai réussi un peu à avancer en mettant le tout à la racine et en utilisant un lien "/mon-pdf.php",
    ça marche à part un pb de session qui disparaît ... m'enfin, je verrai ça plus tard.

    Le pb de cette méthode est que je ne peux inclure la librairie dans mon plugin.
    Je ne vois pas le type de lien je dois mettre à part http://mon-domaine.com/plugins/mon-plugin/mon-pdf.php ?
    je ne sais pas si ça marche mais c'est pas très propre ...

    Il y a aussi le pb de ce dossier font appelé par fpdf.php,
    va falloir que je creuse encore pour trouver quelle valeur modifier pour qu'il aille le chercher au bon endroit.

    M'enfin, j'en peux plus, près d'une semaine de dév' pour ce plugin et lundi faut que je commence son intégration sur le site du client. Vais y aller comme un bourrin et je m'y replongerai après ! :D

    En attendant, vais faire une pause, samedi soir, 19h, une binouse m'appelle ! :D :D :D
    On verra si les bulles vont me permettre d'y voir plus clair ;)
  • StéphaneStéphane Member, Former PluXml Project Manager
    essaye ça

    soit le dossier de ton plugin: /plugins/monplugin
    créer dedans un dossier fpdf
    dans ce dossier copie le contenu du zip de fpdf
    tu devrais avoir un truc du genre

    /plugins/monplugin/fpdf/fpdf.php
    /plugins/monplugin/fpdf/font/

    au debut du fichier php de ton plugin (monplugin.php) ajoute la ligne
    require(dirname(__FILE__).'/fdpf/fpdf.php');
    
    tiens moi au jus (j'ai pas testé)

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • danielsandanielsan Member
    octobre 2011 modifié
    arg,

    en plaçant FPDF dans le fichier du plugin ( sans créer de sous dossier FPDF, mais ça doit aussi marcher ),
    et en appelant mon script de cette manière:
    <a href="<?php echo PLX_PLUGINS; ?>mon-plugin/mon-pdf.php">Voir mon PDF</a>
    
    ça marche!
    mais j'ai apparemment un changement d'encodage alors que lorsqu'il est à la racine, j'ai pas de souci.
    ça tient à rien, c'est pas grave, ça me le génère quand même.
    J'me débrouillerai avec du décode/encode.

    Est-ce que ça pose problème d'avoir ce type de lien ? ( on rend visible l'architecture des dossiers ... )
    J'aurai préféré rester sur un truc du type:
    http:/mon-domaine.com/index.php?mode

    Mon plugin insère un script dans une page de plume.
    Ce script inclut ensuite d'autres script selon certains paramètres envoyés en $_POST.
    Forcément, si je fais
    if($_POST['statut']=='pdf'){include('mon-pdf.php');}
    
    j'ai déjà des lignes présentes avant mon-pdf.php et ça ne marche pas.

    Comment faire en sorte que cet script appelé soit autonome/indépendant ?
    Il faudrait recommencer depuis la fonction header(); en gros ...
    C'est possible de tout détruire et faire commencer mon-pdf.php par cette fonction ?


    Pour mon problème de session qui se détruit entre temps,
    j'avais oublié tout bonnement le
    session_start();
    
    la bière m'a effectivement éclaircit les idées !

    ça s'améliore, me manquera pus que son envoi en pièce jointe d'email !

    Merci pour tout.
  • Jerry WhamJerry Wham Member
    octobre 2011 modifié
    As tu pensé à paramétrer ton fpdf en modifiant le fichier config?

    Est-ce que tu peux nous en dire plus sur ce que tu veux imprimer et les informations que tu récupères?
  • Merci Jerry,

    tout est good, enfin ... presque

    la dernière version ( 1.7 ) de FPDF ne supporte pas l'UTF8,
    j'applique donc la fonction utf8_decode(); sur les variables et ça passe.
    Les variables sont dans une SESSION, donc facile à reprendre.

    Il n'y a pas de fichier config ... juste fpdf.php et le layout que tu crées toi-même
    à moins que j'ai râté quelque chose ...

    Demain je teste comment importer dans le PDF les données enregistrées dans le fichier parameters.xml du plugin ( titre de la page, image, etc ... ).

    Comme FPDF tourne de manière autonome, enfin j'ai l'impression,
    je ne pourrais pas utiliser de méthode propre à PluXml du type
    $titre = utf8_decode( $plxPlugin->getParam('titre_PDF') );
    
    J'ai vu qu'on peut créer d'autres class, mais là ça me dépasse.
    Faudrait limite que je parse de nouveau le fichier parameters.xml du plugin ..?

    Dans le pire des cas,
    je prépare dans l'article sous PluXml un champ caché comportant ces paramètres dans un array();,
    et j'envoi le tout en $_POST ...
    ça c'est si je dois rendre l'ensemble paramétrable, sinon je le fais personnellement en dur :D

    Pour l'utilité de ce plugin, ben c'est un truc particulier pour un client.
    Ceci dit mes différentes recherches pourrait trouver des applications plus large.

    Si quelqu'un a déjà utilisé cet utilitaire avec PluXml ...

    Cordialement,
    _____
    D.San
  • yes! c'est déjà demain ! :D :D :D
    en incorporant et adaptant la fonction loadParams() juste avant mon layaout, ça marche :cool:
    Le titre du PDF renseigné dans la page config du plugin s'incorpore bien dans le PDF généré yahou !
    Merci Stéphane ! :D :cool:

    sur ce, chui pas couché, j'suis r'lancé là !
  • StéphaneStéphane Member, Former PluXml Project Manager
    Ha les joies de l'informatique... :D

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • Jerry WhamJerry Wham Member
    octobre 2011 modifié
    Toutes mes excuses. Je pensais que tu utilisais tcpdf et non fpdf, j'ai lu trop vite. tcpdf est dérivée de fpdf, a un fichier config et elle supporte utf8. On peut l'intégrer plus facilement dans un projet je trouve.

    Vu que tu as pas mal avancé, je ne sais pas si du coup ma remarque te sera utile. Peut-être pour d'autres projets ?
  • @Stéphane: t'as vu ça ? sans me répondre ! ^^^ :D

    @Jerry: mon choix s'est porté sur FPDF car la doc est en français.
    A l'époque j'avais généré mon 1er PDF le temps de boire un café, alors bon... pourquoi chercher ailleurs ?
    Que veux-tu dire par "plus facilement intégrable" ?

    Sinon, le résultat est peut-être bien, mais c'est long ...
    le temps de lire fpdf.php,
    de parser et importer les paramètres du plugin,
    d'importer les variables de la session,
    et faire tourner les fonctions,
    j'espère que ça ira plus vite en ligne !
    Je sais qu'il arrive en pièce jointe d'email avant de s'afficher dans le navigateur ...

    Auquel cas, je pourrais au moins simplifier le parsage en préparant un autre fichier xml dès l'enregistrement de la config du plugin et utiliser simpleXml ?

    ça serait plus rapide comme ça qu'utiliser la méthode loadParams() ?

    Cordialement,
    _____
    D.San
  • Jerry WhamJerry Wham Member
    octobre 2011 modifié
    fdpf est très long au chargement, tout comme tcpdf. Il est même conseillé de modifier le temps de chargement des pages dans le php.ini. Je ne pense pas que cela vienne de ton script.

    Bien sûr si tu peux l'optimiser à fond ce n'est que mieux. Mais je ne pense pas que tu gagneras beaucoup.
    Fais attention aussi, si le document a beaucoup de pages de modifier le php.ini du serveur de prod.

    Voici les prérequis pour tcfdf (qui sont les mêmes que pour fpdf, sauf pour ce qui concerne le fichier de config) extraits de la doc :
    - Install and configure a PHP opcode cacher like XCache;
    - Edit the php.ini file and increase the maximum amount of memory a script may consume (memory_limit);
    - Edit the php.ini file and increase the maximum execution time of each script (max_execution_time);
    - Edit the config/tcpdf_config.php file: manually set the $_SERVER, K_PATH_MAIN and K_PATH_URL constants, and remove the automatic calculation part;
    - If you are not using the Thai language, edit the config/tcpdf_config.php file and set the K_THAI_TOPCHARS constant to false;
    - If you do not need extended chars, edit the config/tcpdf_config.php file and set the default fonts to core fonts;
    - If you do not need UTF-8 Unicode, set the $unicode parameter on TCPDF constructor to false and the $encoding parameter to 'ISO-8859-1' or other character map.
    - By default TCPDF enables font subsetting to reduce the size of embedded Unicode TTF fonts, this process, that is very slow and requires a lot of memory, can be turned off using setFontSubsetting(false) method;
    - Use core fonts instead of embedded fonts whenever possible;
    - Avoid using the HTML syntax (writeHTML and writeHTMLCell methods) if not strictly required;
    - Split large HTML blocks in smaller pieces;
    - Avoid using transactions if not strictly required;
    - Restart the webserver after changes.
    Et voici ce qui est dit dans la faq de fdpf :
    16. Quelle est la taille limite des fichiers que je peux générer avec FPDF ?
    Il n'y a pas de limite particulière. Il existe cependant certaines contraintes :

    - La taille mémoire allouée aux scripts PHP est généralement de 8 Mo. Pour de très gros documents, en particulier avec des images, cette limite peut être atteinte (le fichier étant construit en mémoire). Elle est paramétrée dans php.ini.

    - Le temps d'exécution alloué par défaut est de 30 secondes. Cette limite peut bien entendu être facilement dépassée. Elle est paramétrée dans php.ini et peut être éventuellement modifiée à l'exécution par set_time_limit().

    - Les navigateurs ont généralement un time-out de 5 minutes. Si vous envoyez le PDF directement au navigateur et que vous dépassez cette limite, il sera perdu. Il est donc conseillé pour les très gros documents de les générer dans un fichier, et d'envoyer des données de temps en temps au navigateur (avec un appel à flush() pour forcer l'envoi). Lorsque le document est terminé, vous pouvez effectuer une redirection dessus ou bien créer un lien.
    Remarque : même lorsque le navigateur part en time-out, il est possible que le script continue de s'exécuter sur le serveur.
  • Merci pour ce rappel.
    Il ne s'agit ici que d'une seule page avec un peu de texte et un logo, pas lourd.

    Je connaissais les infos concernant fpdf, les relire confirme ma réflexion:
    Comme j'affiche le PDF dans le navigateur ET l'envoie en pièce jointe d'un email.
    Je crois que je ne vais garder que la seconde soluce qui est plus rapide.
    L'internaute l'aura de cette manière déjà sur son ordi, pas besoin de l'enregistrer etc.

    Et puis c'est bien pour une entreprise d'être dans la boite mails des internautes,
    c'est moins volatile que l'historique web ! :P

    Ce soir je teste l'optimisation de tout ça et posterai le résultat.

    Merci.

    Cordialement,
    _____
    D.San
  • après optimisation, je tombe à moins de 3sec ( contre près de 15s avant ... :cool: )
    Je ne sais pas si on peut descendre en dessous ... :D
    ça reste acceptable :P
  • Je crois que c'est le moment de conclure ce topic ...

    Il est tout à fait possible d'utiliser FPDF avec PluXml.

    1/ Nous pouvons utiliser les paramètres générés par l'écran de config du plugin ( utile pour personnaliser le PDF, par exemple son titre, l'URL du logo, etc ... )
    2/ Nous pouvons utiliser les variables du fichier LANG ( pour les zones fixes, exemple "Date", "Toute l'équipe vous remercie", etc ... )

    Voili voilou !

    Cordialement,
    _____
    D.San
  • je reviens à la charge juste pour dire qu'en optimisant un max le script de génération d'un PDF
    de 2 pages, avec images, en récupérant/formatant des données venant d'une session, du fichier lang, du fichier parameters, et autres,
    la création se fait à la manière de PluXml: quasi instantanée :D je kiffe.

    ( ça me chagrinait cette histoire de 3sec. :D )

    Manque l'envoi en pièce jointe et c'est good.
  • StéphaneStéphane Member, Former PluXml Project Manager
    super boulot

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • merci :P
    attends de voir le truc :D
Connectez-vous ou Inscrivez-vous pour répondre.