Bug entete facture

Using my Dolibarr
1

Hello tutti,

Petit bug noté sur la génération de pdf pour les propales/factures.

De façon aléatoire (il me semble), les coordonnées de l’entreprise et du client, ainsi que la désignation des articles perd sa ‘mise en forme’, au niveau des retours à la ligne.

Exemple, en temps normal on a :

Téléphone: XX XX XX XX XX
Fax: XX XX XX XX XX
Email: xxxxxxx@xxxxxxx.xx
Web: www.xxxxxxx.xx

Et en version bugguée on a :

Téléphone: XX XX XX XX XXF
x: XX XX XX XX XXE
ail: xxxxxxx@xxxxxxx.xxW
b: www.xxxxxxx.xx

Pour la désignation, il ne fait pas les retours à la ligne et coupe les mots. Ca fait tout de suite désordre.

Je peux fournir une capture d’écran si besoin.

Une idée quelqu’un ?
CVS du 20090315

Pièces jointes :

2

Petit complément d’information, en générant plusieurs fois les pdf (10, 20 fois ?), on arrive a tomber sur une version non bugguée, et on peut le voir à la taille du pdf généré (elle change).

Someone ?

3

As tu essayer de lire avec d’autres lecteurs PDF ?

4

Salut Eldy,

Merci pour ta réponse. Je viens d’essayer, même problème.

Vois-tu un lien entre les deux ‘bugs’ (coordonnées entreprise/client et désignations qui ne vont pas à la ligne) ?

J’avais il y a quelques temps un problème différent avec la génération de pdf, ils étaient simplement cassés, illisibles. Il me fallait également les générer 10 ou 20 fois pour en avoir un qui marche. Je le voyais à la taille qui changeait.

Depuis que j’utilise la 2.6dev/beta, je n’ai plus de PDF cassés, juste abîmés :happy:

Merci pour ton aide,

MD

5

hello,

J’avais eu le meme probleme sur la version 2.2 modifiée et à l’époque, on avait trouvé l’astuce en rajoutant des lignes vides dans les adresses clients.

Genre un client lamba avait son adresse ainsi

Mr TARTENPION
3 ALLEE VICTOR HUGO
75001 PARIS

on la mettait ainsi :

MR TARTENPION
<espace vide>
<espace vide>
3 ALLEE VICTOR HUGO
75001 PARIS
. ( le point pouvait aider des fois aussi )

vala

6

Que la taille change à chaque génération peut être normal car il y a un id de longueur aléatoire dans les fichiers pdf. Par contre, pas d’explication sur le pb qui fait qu’au bout de plusieurs génération, il y en a un de bons. Pas d’explication hélas.

7

Salut Eldy et merci pour ta réponse.

Ce que je remarque, c’est qu’il n’y a que 2 tailles de pdf, la mauvaise, et après beaucoup de clics sur ‘générer’, la taille change, et là le pdf est bon.

Peut-être le fait qu’il n’y ait que deux tailles est-il un indice supplémentaire ?

Peux-tu me confirmer que ce bug ne peut pas venir du système ? De la config ou des options d’Apache ? Est-ce bien Dolibarr qui gère la génération de pdf de A à Z ?

(De temps en temps, le pdf généré est directement le bon, pour info)

8

Bonjour,

J’ai exactement le même problème sur un serveur debian testing, et dolibarr 2.6-beta, ou 2.5 , encodage utf8.
Dans quelle direction chercher la solution?
Merci pour cette super appli web.
Frédéric

9

C’est étrange.
C’est bien dolibarr qui génère entierement le PDF en s’appuyant sur la librairie FPDF fourni avec dolibarr mais cela peut provenir d’un bug php ou plus improbable apache. Dolibarr, pourquoi pas, mais alors le coté aléatoire serait surprenant. Il doit y avoir un pb de mémoire mal nettoyé quelquepart donc je penche plus pour PHP ou apache. As-tu essayer avec un debian stable ?

10

Pas moyen de test sur Lenny dans l’immédiat. Le résultat est bon chaque fois que je relance Apache2. J’ignore suite à quoi ca ne passe plus!

11

Helo,

Juste pour dire que ca fait deux jour que je me bat avec le même bug.

Version 2.6dev du 09/04
Ubuntu Server 8.04 LTS

Le bug vient d’apparaitre suite a la mise a jour de 2.5 vers 2.6dev.

C’est vrai qu’en jouant avec des lignes supplémentaires ou des points on peut changer le résultat et parfois le corriger, mais a la 2eme génération rebelote. J’ai beau généré 10 fois, le bug reste.

Jamais eu le prob en 2.5.
De plus, j’ai bien essayer de piquer les fichiers de la 2.5 pr les mettres sur la 2.6dev, mais sans résultat j’ai une page blanche quand je clic sur généré.

12

J’ai peur que le pb viennent d’une fuite mémoire quelquepart.
La 2.5 ne sollicitant pas les meme fonctions et la meme quantité de mémoire. Le fait de résoudre a chaque démarrage d’apache va aussi dans ce sens. Le pb est que avec cela, pas moyen de trouver une correction dans Dolibarr.
Peux-t-etre peux-tu recompiler le php ou installer une autre version. Idem avec apache. Le pb doit venir de l’un des 2.

13

j’ai migré il y a 10 jours de la version 2.2 à la 2.5. Depuis les pdf des commandes clients ont le problème de mise en page en ce qui concerne le champ Emetteur. Le problème est systématique avec la commande Einstein alors que ce même champ est correct pour les pdfs “propositions commerciales” et “factures”.
J’ai sous la main le pdf généré par la version 2.2 et le pdf généré par la version 2.5 si cela peut aider à résoudre.

Configuration : Apache/2.2.3 (Debian) DAV/2 mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch13 mod_perl/2.0.2 Perl/v5.8.8

14

Hi,

Bon finalement pour résoudre ce problème j’ai du convertir ma BD en utf8.
Pour ceux que ca interesse…

Manip pour convertir sa base en UTF8, rapidos :woohoo: :

Manip pour ré-importer la base, via phpmyadmin :

Après quoi, l’en-tête ne bug plus même avec des accents et des caractères bisar. Par contre, la note de fin de proposition ou de facture a tendance a manger le pied de page. L’astuce est d’ajout un retour à la ligne avec un . Pour ajouter une ligne presque vide :stuck_out_tongue: (le point se voit pas trop).

Cdt,

15

Bon, fausse joie ca n’a pas durée le bug est revenu. Et reparti au restart d’apache… Au moins ma bd sera bien en utf8 maintenant, lol.

16

En ce qui me concerne j’ai plus l’impression que le problème est local au modèle de commande Einstein qu’à l’encodage de caractère. J’ai néanmoins essayé de suivre la manip d’adminrezo pour convertir la base en utf8 mais je le retrouve pas dans le fichier sql généré la ligne “DEFAULT CHARACTER SET latin1 COLLATE” en début de fichier. en revanche pour la déclaration de chaque table, j’ai une ligne avec Latin1 : “ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1”.

Est ce qu’il suffit de remplacer Latin1 par utf8 à chaque occurrence ?

Je n’ai pas trop envie de crasher ma base et mon expérience en MySQL est assez limitée.

17

Oui, a mon avis c’est le meme pb.
Cela peut etre du a une mauvaise gestion UTF8 quelque part sur le systeme. Soit une lib utilisé pour compilé PHP, ou Apache (ou mysql).
Quel couple PHP/Apache utilises-tu ?
Et comment sont-ils installé (par package, compil) ?

18

Hi, bon j’ai passé mon ap midi sur ce bug hier.
Je ne pense pas que cela vienne du code Dolibarr mais bien du couple apache/php car j’ai une autre appli qui génère du pdf via ezpdf, et prob quasi identique, 9 fois sur 10 la page généré ds le navigateur est blanche, par contre si j’enregistre le fichier j’ai bien le contenu. Tous ca pour dir que le bug est bien au niveau du php ou de apache, i think, merci pour la piste Eldy, j’ai essayé “Fuite de mémoire apache” dans google mais c’est pas gagné…

Voila ce que c’est de mettre à jour son serveur de prod :s… Donc today vais chercher a réinstaller une version précédente de php car la simple réinstallation apache/php derniere version dans les depots n’a pas suffit.

Le pire dans tous ca, c’est que rien ne sort dans aucuns logs… j’ai cherché partout, enfin je pense…

Pour Latin1 à remplacer par utf8, oui cela suffit, car cette ligne 1er ligne “DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci” est en quelque sorte ta variable , si tu as fait comme je l’ai ecrit plus haut ca marhe sans prob. Et ca ne fait pas de mal, j’ai moins de prob d’accent ainsi.

Ouvert à tout tester :happy:

Oups oublié version PHP, installé par le depot ubuntu

PHP Version 5.2.4-2ubuntu5.6
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
This server is protected with the Suhosin Patch 0.9.6.2 Copyright © 2006 Hardened-PHP Project

Version Apache2
Version 2.2.8.1ubuntu0.5

Version noyau,
System Linux kernel 2.6.24-23-server

Version mysql,
MySQL Support enabled
Active Persistent Links 1
Active Links 1
Client API version 5.0.51a

A oui, outre l’update du serv de prod on a aussi installé egroupware je ne sais pas si ca peu avoir un lien… je pense pas je ne suis pas encore sur cette piste, mais si vous dites que vous aussi, alors je chercherais par la…

19

Bon, je m’oriente sur un conflit php5-mysql & php5-mysqli.
Problème est que si je désactive l’extension mysqli dans apache, impossible d’accéder à Dolibarr.

Mysqli driver are not available in this version of PHP. Try to use another driver.
DatabaseTypeManager: mysqli

20

Essai aussi de voir au niveau des lib pdf. Il peut y avoir des lib apache ou php qui y accèdent en dynamique.

Si tu désactive l’extension mysqli, il faut activer l’extension mysql a la place et modifier ton fichier conf.php pour refleter le changement.