Bonjour,

Un post pour un problème et sa solution... au cas où ça puisse intéresser quelqu'un un jour.

Symptôme:
1. Génération de PDF avec FPDF. Deux modes d'utilisation:
a. Génération du PDF en ligne dans le navigateur, consultation sur écran -- OK pas d'erreur.
b. Génération du PDF sur le serveur, traitement de ce PDF par pdf2ps, puis par gs pour le transformer en PCL, envoi du PCL en mode raw sur CUPS par la commande lp -- Impossible de créer le fichier PCL.
c. Si j'enregistre sur le disque dur de mon PC le fichier obtenu en b, celui-ci est corrompu je ne peux l'ouvrir.

Diagnostique :
Je crée le même fichier PDF, mais une fois en ligne et une fois enregistrée sur le serveur. Le fichier généré en ligne, je l'enregistre ensuite sur mon disque dur. Quand je compare la source des deux fichiers, ils sont identiques à l'exception de la directive /MediaBox [0 0 595,28 841,89].
Dans un cas le séparateur décimal des dimensions est une virgule (fichier corrompu) dans l'autre un point (fichier correct).
Dans le source de fpdf, je constate que cette directive est générée par sprintf, et que le spécificateur de type est f (et non F). Or le spécificateur de type f utilise les locales (pas F) !!!!

Conclusion:
FPDF est sensible aux locales à cause d'un mauvais usage de sprintf. Néanmoins ce problème n'est pas visible en temps normal car il semblerait que le navigateur ré-interpréte à la volée les valeurs des mediabox pour les convertir correctement. Ce problème est par contre visible dès que vous voulez réaliser des traitements sur les fichiers PDF générés. Dans mon cas il s'agissait de rediriger ce PDF vers une imprimante PCL sur le réseau, d'où des transformations ... et pdf2ps est moins souple que mon navigateur

Solution:
Forcer les locales dans le système décimal américain sur fpdf... ou modifier toute la source de fpdf en changeant les appels à sprintf.

Pour que ça serve, Théolude