developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 13 years ago

Closed 12 years ago

#131 closed new feature (fixed)

adding a pdf response

Reported by: laurentj Owned by: Julien
Priority: normal Milestone: Jelix 1.0 RC1
Component: jelix:core response Version:
Severity: minor Keywords: pdf response
Cc: Blocked By:
Blocking: Documentation needed:
Hosting Provider: Php version:

Description

Jelix should provide a jResponsePdf. Perhaps we can use FDPF class.

Attachments (3)

patch_jResponseFpdf.tgz (16.7 KB) - added by Uriel C 13 years ago.
Patch pour un jResponseFpdf
jResponseTcpdf.patch (9.7 KB) - added by Julien 12 years ago.
PDF Response based on TCPDF
default.classic.php (2.5 KB) - added by Julien 12 years ago.
Sample controller for jTcpdf

Download all attachments as: .zip

Change History (38)

comment:1 Changed 13 years ago by laurentj

A solution is to add some pdf response with each library we can found :

Changed 13 years ago by Uriel C

Patch pour un jResponseFpdf

comment:3 Changed 13 years ago by Uriel C

Je viens d'attacher un patch permettant d'utiliser un jResponse basé sur FPDF (jResponseFPDF). Ne sachant trop ou placer fpdf et son dossier font/ j'ai placé cela dans lib/jelix/utils. Le chemin est modifiable grace a un define.

Exemple d'utilisation :

     $rep = $this->getResponse('fpdf');
     $rep->FPDF();
     $rep->AddPage();
     $rep->SetFont('Arial', 'UI', 16);
     $rep->Cell(50, 20, 'Hello, world !', 1);
     return ($rep);

comment:4 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.0 to Jelix 1.3

comment:5 Changed 13 years ago by laurentj

  • Priority changed from low to high

comment:6 Changed 13 years ago by bastnic

Si jamais utilisation de FPDF : plutôt utiliser UFPDF : support d'UT-8 http://acko.net/blog/ufpdf

comment:7 Changed 13 years ago by Uriel C

Pour cela, il suffit à priori de remplacer le fichier fpdf.php par celui de UFPDF, vu que l'auteur dit :

"UFPDF works the same as FPDF, except that all text is in UTF-8, so consult the FPDF documentation for usage."

En outre mon patch ne manipule pas les chaines qu'on lui passe. Tout devrait donc être transparent.

comment:8 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.3 to Jelix 1.0
  • Priority changed from high to normal

comment:9 Changed 13 years ago by laurentj

Je viens de découvrir qu'il y a dans PEAR une classe, File_PDF, récente et qui est un fork de FPDF. Elle est développée par les dev de horde et disponible dans horde.

comment:10 Changed 13 years ago by laurentj

Encore une autre solution, basée sur fpdf : http://www.setasign.de/products/pdf-php-solutions/fpdi/ . Avantage : on peut charger un pdf existant et le modifier.

comment:11 Changed 13 years ago by laurentj

@uriel : toutes bibliothèques externes sont à mettre dans le répertoire lib/ tout simplement, et non pas dans lib/jelix/utils puisque lib/jelix ne contient en principe que les sources de jelix. donc FPDF serait à mettre dans lib/fpdf/.

comment:12 Changed 13 years ago by bastnic

J'ai un problème de polices avec ufpdf.

A voir plutôt qu'ufpdf : TCPDF http://www.tecnick.com/public/code/cp_dpage.php?aiocp_dp=tcpdf http://sourceforge.net/projects/tcpdf/

Je regarde ce que j'arrive à en faire.

comment:13 Changed 13 years ago by laurentj

@bastnic : des nouvelles de tes essais avec TCPDF ?

comment:14 Changed 13 years ago by bastnic

Laurent, je suis suroverbooké par l'approche de mes partiels et par tous les DS et projets que je dois finir. Je ne pourrais pas retoucher à Jelix avant le 17 décembre.

Pour répondre à ta question, TCPDF a l'air très puissant, bien plus à jour qu'fpdf qui semble plus ou moins abandonné. Mais il produit des fichiers horriblement lourds. Pour la même chose, c'est à dire même pas une page de texte : FPDF : 8ko TCPDF : 153ko

Pour plusieurs pages dont tableaux : FPDF : 141 ko TCPDF : 688 ko

C'est insupportable. Je n'ai pas pris le temps d'approfondir les raisons de ce surpoids. Mais je vais pas pouvoir t'aider sur ce coup.

A dans trois semaines.

comment:15 Changed 12 years ago by Julien

Salut,

j'utilise depuis un certain temps TCPDF, qui marche très bien pour l'UTF-8, avec effectivement la même API de base de FPDF.

Pour le surpoids, j'avoue ne pas y avoir prêté attention, en tout cas je n'ai pas souvenir avoir été choqué par des fichiers très gros. Je vais vérifier.

Un élément de réponse au hasard : le support de l'UTF-8 ne pourrait-il pas être en partie responsable ? Bien entendu, ce ne serait qu'une raison très partielle.

Je veux bien y jeter un oeil cette semaine, je posterai les conclusions ici.

comment:16 follow-up: Changed 12 years ago by laurentj

le support de l'UTF-8 ne pourrait-il pas être en partie responsable ?

Je ne pense pas. Au pire, la taille serait multiplié par deux, et encore les caractères les plus courant pour le français ou l'anglais, sont codés seulement sur un octet. Vu que l'on a à faire a des surconsommation x5, x20, à mon avis, elle vient d'ailleurs, donc de l'implémentation de TCPDF.

Faudrait-voir si TCPDF n'ajoute pas des données inutiles dans l'en-tête, genre un message du style 'produit par TCPDF', etc. Est ce qu'il n'embarque pas la fonte non plus ? (je raconte peut être une connerie, vu mon ignorance sur le format PDF). Bref, regarder si dans le paramétrage de TCPDF, on ne peut pas améliorer les choses.

comment:17 Changed 12 years ago by bastnic

Laurent : il y a de fortes chances que tes hypothèses soient les bonnes. Dès le 17 j'attaque le dev du plugin qui ne doit pas êrre si dure que ça : il suffit de repdrendre le patch sur fpdf, déplacer au bons endroits les sources de tcpdf, fournir le patch et faire tester.

On est qu'en RC1 donc il peut encore y avoir quelques bugs dans la gestion de TCPDF : les gens feront des rapports de bugs.

Je me trompe ?

comment:18 in reply to: ↑ 16 Changed 12 years ago by Julien

Replying to laurentj:

le support de l'UTF-8 ne pourrait-il pas être en partie responsable ?

Je ne pense pas. Au pire, la taille serait multiplié par deux, et encore les caractères les plus courant pour le français ou l'anglais, sont codés seulement sur un octet. Vu que l'on a à faire a des surconsommation x5, x20, à mon avis, elle vient d'ailleurs, donc de l'implémentation de TCPDF.

oui, c'est pour cela que je l'évoquais comme une petite partie de l'explication.

Faudrait-voir si TCPDF n'ajoute pas des données inutiles dans l'en-tête, genre un message du style 'produit par TCPDF', etc. Est ce qu'il n'embarque pas la fonte non plus ? (je raconte peut être une connerie, vu mon ignorance sur le format PDF). Bref, regarder si dans le paramétrage de TCPDF, on ne peut pas améliorer les choses.

Effectivement, j'ai pris un PDF généré par TCPDF (172ko). En l'ouvrant puis en l'enregistrant tel quel en PDF avec Aperçu (MacOSX), il tombe à 88ko.

Donc soit y a 100Ko d'entêtes ou de choses inutiles, soit il y a plusieurs façons d'écrire un document PDF, et TCPDF n'optimise rien du tout dans ce sens. Etant également une bille sur le format PDF, j'avoue ne pas trop savoir.

Sinon effectivement, pour la substitution FPDF/TCPDF dans le patch actuel, il n'y a pas vraiment de problème.

comment:19 Changed 12 years ago by Julien

Re,

ça vient des polices effectivement, qui sont embarquées dans le PDF.

Quand on sait qu'il y a des fichiers fonts qui pèsent 300+ Ko, forcément....

La mauvaise nouvelle, c'est que TCPDF ne semble pas fonctionner sans inclure les fonts (j'ai commenté leur importation à l'arrache sans chercher plus loin pour le moment).

La vraie question, c'est de se demander si c'est une bonne chose ou pas que les fontes soient embarquée. Si oui (c'est mon avis), alors le problème du poids ne se pose pas vraiment. Sinon, je ne sais pas trop.

Je ne sais pas comment se débrouille Aperçu pour optimiser (est-ce qu'il enlève la police embarquée ?).

De mon point de vue (de bille en PDF, je le répète), le poids n'est pas réellement un problème, si l'on considère que l'inclusion des typos permet la restitution du document telle que prévue par l'auteur. Bref, c'est pas un bug, mais une fonctionalité ;)

Vous en pensez quoi ?

comment:20 Changed 12 years ago by laurentj

À mon avis, c'est un bug. Un lecteur PDF à priori sait utiliser les fontes systèmes, donc on devrait normalement pouvoir s'en passer (Pouquoi inclure Courier alors qu'elle est installée sur 99% des systèmes ?).

Sinon j'ai jeté un coup d'oeil à TCPDF

  • Je trouve son code pas super propre et optimisée, mais bon, passont..
  • C'est livré avec une tonnes de fontes, et même en prenant le minimum, ça va m'alourdir l'archive de Jelix de 500-600%. Ajouter 4Mo de fontes (9mo si on prend tout) dans un truc qui ne fait que 700ko à la base, ça m'embête beaucoup.

Alors que fait-on ? Fera-t-on un package spécifique avec les fontes à parts ? Laissera-t-on le développeur télécharger TCPDF tout seul comme un grand (et on livre juste le jResponse qui va bien) ?

comment:21 Changed 12 years ago by bastnic

C'est une idée la fourniture de JResponse uniquement, on pourrait le faire pour FPDP, UFPDF et TCPDF, ça ne serait que trois fichiers.

Après faudrait voir. Beaucoup de sites webs utilisent FPDF avec encodage/décodage à la volée des chaines de caractères. UFPDF je sais pas pourquoi j'ai toujours des problèmes de fonts, d'espace trop grand entre les lettres et j'en passe et des meilleurs. Pour finir, TCPDF résoud bien tous mes problèmes d'encodage, de fonts mais énormément consommateur en bande passante et en espace disque.

En tout cas je n'ai pas trouvé de solutions ultimes à l'heure actuelle alors je suis pour la préexistence des JResponses puis on se débrouille avec les sources. Limite on publie sur jelix.org les tar.gz qui vont bien...

comment:22 Changed 12 years ago by Uriel C

Ca parle des polices incluses dans la doc de FPDF : http://www.fpdf.org/fr/tutorial/tuto7.htm

Sinon on peut inclure TCPDF, et juste un set minimal de polices (celui de FPDF), et proposer à côté le téléchargement du pack "complet" de TCPDF. Ca reste utilisable "out of the box" sans pour autant alourdir l'archive (et les fichiers générés) de plusieurs Mo.

Ou faire un script d'installation des polices supplémentaires, avec un contrôleur dédié à ça dans le module jelix : jelix~extensions par exemple.

comment:23 Changed 12 years ago by Julien

Oui, genre 2 polices de base ça me semble bien (moi j'utilise presque tout le temps "vera") : 1 serif et 1 sans-serif, avec une archive complète en option, téléchargeable sur le site jelix (il suffirait de remplacer/completer le dossier /lib/tcpdf).

Sinon, je pense que l'inclusion des polices est là pour des questions de copyright sur les polices "standard" (désolé si je raconte n'importe quoi, je suis pas sûr de mon coup, mais je crois bien que les polices sont très protégées).

Donc on a pas d'arial, de times, etc... mais des équivalents "libres".

Comme il y a certaines fonctions de TCPDF qui calculent la taille (longueur, hauteur) des chaines de caractères/cellules, je pense qu'il doit être obligé de le faire sur des polices qu'il maitrise.

Pour les même raisons, la police doit être embarquée, pour que le document ne soit pas "décalé" par la suite (si les dimensions ont été calculées sur une police qui est substituée chez l'internaute)

J'ai en tout cas l'impression que TCPDF est la seule classe parmi celles testées qui répondent bien aux besoins, notamment le support de l'UTF-8.

comment:24 Changed 12 years ago by laurentj

Je viens d'inclure TCPDF dans le trunk de jelix (lib/tcpdf), avec un répertoire lib/fonts qui contient toutes les fonts. J'ai modifié les scripts de builds de jelix pour pouvoir inclure ce repertoire lib/fonts ou non via une option INCLUDE_ALL_FONTS dans le ini du build (pour les packages par défaut de Jelix, c'est à false). Et j'ai rajouté un script qui permet de générer un package séparé pour les fonts.

J'ai modifié la config de tcpdf (dans lib/tcpdf/tcpdf_config.php) pour qu'il tienne compte de l'arborescence de jelix. Je n'ai par contre pas testé, donc peut être y aura-t-il à faire quelques ajustements.

Donc j'attend un patch qui contient le jresponse qui va bien. Je pense aussi qu'il sera préférable de faire une classe héritant de celle de tcpdf, et surchargeant la méthode error(), parce que celle-ci fait un die, ce qui n'est franchement pas propre. Ce serait mieux qu'elle fasse une exception.

comment:25 Changed 12 years ago by laurentj

Pour être plus clair : les fontes ne sont pas incluses par défaut dans les paquets Jelix, il faudra les télécharger à part (après tout, tout le monde ne fait pas du pdf..)

comment:26 Changed 12 years ago by Julien

Laurent,

je ne sais pas si les fontes sont exploitables par autre chose que TCPDF, on pourrait donc peut-être les laisser des /lib/tcpdf/fonts comme pour la distrib par défaut ? Ce serait également plus facile pour mettre à jour. Après je ne sais pas si ça peut poser problème au niveau des scripts de build, mais je pense pas. Sinon renommer en /lib/tcpdf_fonts.

Bien entendu, si les fonts sont exploitables par autre chose que TCPDF (à vérifier), alors j'ai rien dit.

Il faut peut-être envisager une classe genre jPDF qui puisse être utilisée sans être forcement dans une jResponsePdf (par exemple pour simplement enregistrer le pdf sur le disque, lors du traitement d'un jForm par exemple), un peu comme jJSON par exemple, qui fait l'intermédiaire entre la réponse et la classe extene Json.

Pour finir, la réponse devrait s'appeler jResponsePdf ou jResponseTcPdf ou autre chose ? Sommes-nous suceptibles d'intégrer une autre classe PDF un jour dans Jelix ?

Je veux bien me lancer dans le patch une fois ces questions réglées, à moins que quelqu'un soit déja sur le coup ?

comment:27 Changed 12 years ago by bastnic

Je te laisse faire Julien.

comment:28 Changed 12 years ago by laurentj

À priori, ce sont des fichiers fontes qui sont incorporés directement dans le PDF. Donc ça peut être utilisé par d'autres generateurs de pdf. Mais normalement tu n'a pas à t'occuper de ce répertoire, puisqu'il est indiqué dans la config de TCPDF. Je verrais si il faut le bouger ou pas.

Pour la classe jPdf (à placer dans jelix/utils/), oui pourquoi pas, de toute façon, comme je le disais, il faut en faire une pour l'histoire de error().

La réponse devrait s'appeler jResponseTcpdf (avec le code "tcpdf"). Sinon oui, on est suceptible d'intégrer une autre classe PDF si on trouve d'autres moyens de génerer un pdf. Aprés tout, il y a bien déjà une response jResponseLatexToPdf ;-)

comment:29 Changed 12 years ago by Julien

  • Owner changed from laurentj to Julien

Ok je m'y colle à partir de demain.

Changed 12 years ago by Julien

PDF Response based on TCPDF

comment:30 Changed 12 years ago by Julien

Salut,

je viens de poster le patch.

J'ai fait relativement simple :

jResponseTcpdf utilise en gros le même schéma que jResponseBinary (propriétés $outputFileName et $doDownload).

Il suffit de placer une instance de jTcpdf dans la propriété $tcpdf de la réponse.

jTcpdf redéfinie simplement la méthode error() de TCPDF pour lancer une exception.

J'ai rajouté la méthode utilitaire jTcpdf::saveToDisk() pour faciliter l'enregistrement sur le disque (même si TCPDF le permet de base, c'est sans doute plus explicite ainsi, et ça peut permettre éventuellement de mieux gérer le problème d'enregistrement).

la propriété $tcpdf de jResponseTcpdf est nulle à la base, car en général on surcharge la classe de base TCPDF pour redéfinir les méthodes Header() et Footer(), en fonction du document à générer.

Cette propriété doit donc contenir une instance jTcpdf (qui hérite de TCPDF) ou alors une instance d'une classe fille de jTcpdf, dont le développeur aura justement redéfini les méthodes nécessaires. Dans tous les cas, c'est au développeur de créer explicitement l'objet PDF.

Je poste un contrôleur exemple qui montre tous ces cas.

Julien

Changed 12 years ago by Julien

Sample controller for jTcpdf

comment:31 Changed 12 years ago by laurentj

Je verrais en détails ton patch plus tard, mais aprés une première lecture rapide, ça me parait bien.

comment:32 Changed 12 years ago by laurentj

  • Resolution set to fixed
  • Status changed from new to closed

J'ai inclus le patch dans le trunk. J'ai ajouté la méthode FPDF (renommée en initPdf) et la méthode _call que Uriel avait proposé dans son patch, car j'ai trouvé que c'était interressant.

Merci pour les patchs !

comment:33 Changed 12 years ago by Julien

Parfait ;)

effectivement, initPDF peut faire gagner du temps quand on a pas à redéfinir un header, un footer, etc... pour pouvoir rendre ces éléments plus riches en terme de mise en page qu'avec les méthodes par défaut.

sinon, je pense que tu as copié-collé un peu vite :

public function __call($method, $attr){
    if ($this->fpdf !== null){
        return call_user_func_array(array($this->fpdf, $method), $attr );
    }else{
        throw new jException('jelix~errors.reptcpdf.not_a_jtcpdf');
        return false;
    }
}

faut remplacer $this->fpdf par $this->tcpdf ;)

comment:34 Changed 12 years ago by Julien

  • Resolution fixed deleted
  • Status changed from closed to reopened

ooops, oublié de ré-ouvrir

comment:35 Changed 12 years ago by laurentj

  • Resolution set to fixed
  • Status changed from reopened to closed

Typo corrigé. Merci :-)

Note: See TracTickets for help on using tickets.