1

J'ai deux soucis :

le code ’ n'est pas interprété dans le PDF

Il pourrait y avoir des soucis avec les balises inconnus ? Ce que je transforme en PDF est du texte saisi via FCKEditor et parfosi déjà copié/collé de word, avec évidement un tas de code html surement pas trop reconnu...

Si besoin je peux fournir des liens (en privé car le site est en developpement) vers les pages qui posent soucis, il ya peut etre une analyse à faire pour comprendre certains bugs...

2

HTML2PDF est fait au départ pour créer des docs officielles (style facture et autres), et non pour que des utilisateurs puissent directement depuis un WYSIWYG rentrer un code HTML pourri pour ensuite le convertir. Le code HTML fournit à la lib doit être absolument propre... Alors quand en plus il est directement copié de Word... cheeky

comme marqué dans le fichier exemple about.php :
# Elle ne permet généralement pas la conversion directe d'une page HTML en PDF, ni la conversion du résultat d'un WYSIWYG en PDF. # Cette librairie est là pour faciliter la génération de documents PDF, pas pour convertir n'importe quelle page HTML.


Donc il faut que tu nettoies le code HTML avant de le convertir...

Ancien pseudo : lolo

3

tiens Spipu, je n'ai pas regardé ton code donc je sais pas si ton parseur est remplaçable facilement, mais si oui peut-être que simplehtmldom serait une bonne alternative ? c'est un petit parseur HTML -> DOM que j'ai déjà utilisé pour un projet perso, il a l'avantage d'être très simple à utiliser et de plutôt bien résister aux pages invalides, le tout en un seul fichier de 30ko ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

4

en effet, il a l'air assez facile d'utilisation et assez complet. Je pense que je vais me l'utiliser pour parser mes pages moi smile j'ai quelques scripts perso qui pourraient en profiter happy

concernant son application dans HTML2PDF, le pb c'est qu'en fait mon parseur ne fait pas HTML -> DOM mais HTML -> Instructions pour HTML2PDF. Donc je pense que je serais obligé de reconvertir intégralement ce qu'il me sortira sad

après, autre petit pb : il nécessite PHP5, or ma lib ne nécessite que PHP4 (étant basé sur FPDF) => pas glop.

enfin concernant les WYSIWYG, le pb est que très souvent ils ne font pas du code valide.

par exemple, ils font ceci pour une double liste à puce :
<ul><li>1</li><ul><li>1.1</li></ul></ul>

au lieu de
<ul><li>1<ul><li>1.1</li></ul></li></ul>

c'est comme si t'avais deux <table> qui se suivent, ou directement un <td> dans un <table> sans <tr>... dans ce cas là ta lib parserait certe impec le code HTML sans souci, mais ne corrigerait pas ces énormités que peuvent sortir les WYSIWYG. et du coup il y aurait tjrs des pbs au final lors de la conversion.

c'est bien pour ca que je leur ai marqué de partout qu'il fallait que le code HTML soit valide, et pas juste que les balises soient fermées comme il faut.

Et puis comme ca ca leur apprendra à faire du HTML propre... Le nombre de personnes qui veulent faire du PHP alors qu'ils ne savent même pas faire de l'HTML/xHTML.. j'ai jamais compris cà ! c'est comme si ils voulaient être garagistes sans rien comprendre aux voitures...

en tout cas, merci pour l'info, cette lib a l'air assez intéressante !
Ancien pseudo : lolo

5

# Elle ne permet généralement pas la conversion directe d'une page HTML en PDF, ni la conversion du résultat d'un WYSIWYG en PDF. # Cette librairie est là pour faciliter la génération de documents PDF, pas pour convertir n'importe quelle page HTML.


Pour le code qui doit etre propre, soit. Mais du code propre cela peut commencer par des balises qui s'ouvrent et se ferme correctment. Après si ta class ne connait pas certaine balises, elle peut ene faire abstraction, tant pis pour celui qui les utilise. Moi je voyais plutot cela comme ça.

C'est sur Word c'est ce qu'il y a de pire, mais que je vire avant de passer à la class le HTML inconnu ou que ta class le fasse elle même...

Le plus gros regret c'est justement coté Parser, quand il detect quelque chose qui n'est pa sfermé ou ouvert correctement il ne dit pas ou... parfois sur des mises en pages de tableau effroyable ca aide.. surtout quand on ne fait plus de tableau et que des div depuis longtemps, se replonger là dedans c'est la cata...

En tous cas merci pour ta class qui remplace avantageusement html2fpdf !

6

je m'avance peut-être, mais il me semble justement que les pages HTML générées par Word sont complètement invalides ? ce n'est pas un problème de balise non reconnue (je suppose que HTML2PDF ignore tout simplement les balises correctes mais qu'il ne sait pas rendre), plutôt de page invalide.

si ce n'est pas ça le problème, tu peux poster le code HTML responsable de l'erreur ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7

Zephyr (./6) :
je suppose que HTML2PDF ignore tout simplement les balises correctes mais qu'il ne sait pas rendre

ben en fait non, mais en meme temps, il ne reste plus bcp de balises qu'il ne connait pas...

et puis pour trouver où se situe l'erreur, il suffit de passer le 2em paramètre de la méthode writeHTML à true. Comme ca, HTML2PDF te retournera le code HTML, et il suffit alors d'utiliser un valideur de code (comme celui du W3C, ou plus simplement l'extension HTML VALIDATOR de firefox)

le but de HTML2PDF n'est pas de dire où sont les erreurs dans un HTML non valide, mais de convertir de l'HTML valide... Et jamais HTML2PDF n'aura cette première fonction, car sinon ca impliquerait une methode de parsing un peu plus complexe... Or il prend déjà assez de ressource comme ca.

et puis faire des regex afin de rendre valide un code non valide, ce n'est pas bien compliqué... Donc il te suffit de faire un pré traitement avant d'envoyer le code HTML à ma LIB...
Ancien pseudo : lolo

8

Spipu (./7) :
ben en fait non, mais en meme temps, il ne reste plus bcp de balises qu'il ne connait pas...

ah bah c'est dommage ça parceque pour le coup ça bloque potentiellement plein de pages alors que c'est tout aussi simple d'ignorer silencieusement la balise, non ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

9

sisi,et en effet c'était le cas avant (le fait de bloquer potentiellement), mais maintenant les seules balises non prises en charge (il me semble) sont html, head, body, et tout ce qu'on peut mettre dans le head (à part les styles css et link pour les css egalement).

du coup, on n'est normalement plus bloqué par l'absence de prise en charge de certaines balises.

Si les balises html, body, et head ne sont pas prises en charge, c'est parce que d'autres balises spécifiques ont été introduites pour permettre une mise en page plus adapté au format PDF

cf http://wiki.spipu.net/doku.php?id=html2pdf:fr:page

[nosmile]
Ancien pseudo : lolo

10

Pour la validation HTML et le pb du parser, tu fais le bon choix je pense finalement, il vaut mieux que ton parser soit rapide effectivement. D'ailleurs pour des pages toutes bêtes (un grand tableau de 3 colonnes sur 2 pages A4) c'est tres lent, me demande pourquoi. Mais c'est viable donc tant pis. les retours à la ligne sont parfois pas terrible dans les cellules de tableau, je vais regarder si cela a été signalé ou si ya moyen de... moyenner.

Je n'ai pas eu le temps de rebosser sur ces copier/collé de word dans FCKeditor mais je vais le faire, en mettant un parser en amont pour nettoyer le code, voir ce que cela donne.

De mon coté en, général si je genere du PDF c'est que j'ai un HTML déjà généré soit pour affichage soit pour impression donc le but est de ne pas reprogrammer une sortie PDF mais de s'appuyer sur html2pdf. Et ca marche plutot bien je dois dire.

Pour les erreurs je fais comme tu dis, en utilisant un plugin Validateur HTML sous Mozilla.

11

Punky65 (./10) :
(un grand tableau de 3 colonnes sur 2 pages A4) c'est tres lent


heu, combien de temps ca te prend pour la génération d'un simple tableau comme ca ?!

sinon, petite méthode d'optimisation, il vaut mieux éviter d'inbriquer trop de divs et de tables les une dans les autres, car pour chaque élément, il est obligé de précalculer entierment ce que ca va donner pour pré calculer les dimensions. Donc il vaut mieux éviter les tableaux imbriqués, et plutot joué sur les colspan rowspan, et les styles.
Ancien pseudo : lolo

12

je repond apres longue absence !

A générer ca prend 25 à 50 scondes sous Wamp... et sur le serveur entre 8 et 15 secondes. j'ai fait de l'ajax pour faire patienter ca marche bien.

Par contre bien que nettoyant au max, il reste un truc qui me chagrine : les <span /> ne sont pas compris dans ton code. Certe c'est stupide mais rien ne l'interdit.....

13

les span ?? normalement ils sont compris ! en quoi ils ne sont pas compris chez toi ?
Ancien pseudo : lolo

14

bin j'avais un code pourri (oui je sais, mais jele dis honettement !) du genre :
<font><font><font><span /></font></font></font>
et visiblement il ne comprend pas le <span /> !

15

ah non, ca c'est normal, c'est du xhtml, et pas de l'html. il ne comprend pas les balises automatiquement fermées. il faut remplacer <span/> par <span></span>.
Ancien pseudo : lolo

16

ya pas un moyen de patcher ? ca doit pas etre compliqué, j'ai regardé ton code un peu... mais pas le temps de l'approfondir.

17

cela sera corrigé dans la prochaine version de HTML2PDF
Ancien pseudo : lolo

18

ok, date de sortie ? (oui je suis chiant en plus ... ;-))

19

topics/123704-nouvelle-version-html2pdf-v324#1

beaucoup de choses à rajouter et à tester !

wink
Ancien pseudo : lolo

20

Misplaced - sorry