v 4.01 : Parsing des styles inline apres tidy (résolu) - Page 1

1

Le 16/10/2010 à 20:42

Dans la fonction function analiseCode($code) de la class parsingHTML, il y a quelques problemes de parsing pour les styles (config: serveur WAMP, HTML2PDF v4.01).
Quand on passe par tidy pour nettoyer, il peut y avoir des retours ligne ajoutés:
et le style n'est pas parsé correctement par le regex:

exemple html original:


avec possible petits abcès dans le lobe


devient apres tidy :

avec possible petits
abcès dans le lobe

et le style n'est pas parsé. Rq: si on ne passe pas par tidy , un simple espace entre = et "

test
le style n'est pas parsé non plus, bien que le HTML semble OK.

J'ai donc ajoute au debut de analiseCode la ligne

$code = preg_replace("/(\r\n|\n|\r)/", "", $code);
Pour supprimer le retour ligne. Je ne sais pas si cela peut avoir des side-effect.(pas vu pour l'instant)

2

Le 17/10/2010 à 18:50

heu, en même temps, c'est autorisé par le W3C ou pas cette syntaxe ? c'est à vérifier... car je pense que la ligne que tu as rajouté peut avoir des effets secondaires assez embêtant, notamment pour les textarea et autres...

Ancien pseudo : lolo

3

Le 18/10/2010 à 00:17

En fait, c'est parce que j'utilise un editeur html pour pouvoir créer des Compte rendu d'examen d'imagerie qui contiennent texte HTML enrichi et image.
Pas de problème pour les entetes, les champs fusionnés, mais par contre je ne contrôle pas le contenu HTML qui sort de l'éditeur.
Le HTMl qui sort de ce type d'éditeur n'etant pas très clean (vieille balise HTMLsur IE, melange de style pour les font-family et de balise SIZE sous firefox, etc..) je fais un passage pour transformer les anciennes balises en style inline dans des SPAN, et pour être sur d'avoir qqchose de propre, j'utilise tidy sur la sortie.

J'avais des résultats bizarres : certaint styles n'était pas pris en compte. C'est en regardant le HTML sortant de tidy que j'ai vu les retour chariot ajoutes.

Avec le Regex, je n'ai plus de problème, maintenant tout est nickel (variation de taille de police, de police, de couleur imbrique, etc...)

Pour le textarea, je vais faire des essais (je n'ai pas utilisé cette balise jusqu'à présent).
Je te tiens au courant.

En tous cas, super boulot.
Et j'essaie de te faire sponsoriser

4

Le 18/10/2010 à 09:16

Plutot que de rajouter ds html2pdf un truc avec des effets secondaires, je te conseillerais plutot de corriger ton html avant de l'envoyer a html2pdf, une utilisant une regex

Ancien pseudo : lolo

5

Le 18/10/2010 à 13:25

Pour la conformance W3C, je pensais justement que tidy était une sécurité.
En tout cas une page contenant

avec possible petits
abcès dans le lobe

passe sans probleme au 'markup validation service' du W3C
Comme il m'a semblé apres un survol rapide du code que l'action analiseCode portait sur la balise, j'ai ajoute le regex à cet endroit.

Donc il faut un regex qui enleve les saut de ligne à l'interieur d'une balise, avant envoi comme tu le propose ou dans HTML2pdf. Je pensais que le faire dans HTML2PDF rendait le convertisseur moins sensible à des problemes de formatage indépendant du W3C

Je continue à faire des tests...

Cdlt