6.0.0-beta1
7/6/25

[#4094] File/PDF.php - Bug since PHP 4.3.10 with certain locales
Summary File/PDF.php - Bug since PHP 4.3.10 with certain locales
Queue Horde Framework Packages
Queue Version HEAD
Type Bug
State Resolved
Priority 2. Medium
Owners wrobel (at) horde (dot) org
Requester thomas (at) gelf (dot) net
Created 06/29/2006 (6947 days ago)
Due
Updated 09/14/2007 (6505 days ago)
Assigned 07/03/2006 (6943 days ago)
Resolved 09/14/2007 (6505 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
09/14/2007 09:40:14 AM Jan Schneider Comment #8
Assigned to Gunnar Wrobel
State ⇒ Resolved
Reply to this comment
Committed, thanks.
09/12/2007 06:56:23 PM Gunnar Wrobel Comment #7
New Attachment: File_PDF-locales_bug-20070912.patch Download
Reply to this comment
Updated as suggested. Looks ugly but should be easy to remove once PHP 
< 4.3.10 is not being supported anymore.
04/11/2007 12:09:28 AM mattias (at) thorslund (dot) us Comment #6 Reply to this comment
Thomas,



Thank you very, very much for this patch! It helped me fix this 
difficult problem...



Mattias


10/05/2006 12:11:51 PM Jan Schneider State ⇒ Stalled
 
08/04/2006 10:13:50 PM Jan Schneider Comment #5 Reply to this comment
Are you going to update your patch?
07/05/2006 11:23:57 AM Jan Schneider Comment #4 Reply to this comment
A 3rd alternative would be to set the locale to en_US during the the 
sprintf() calls, but that would mean a lot of locale switching back 
and forth inside the methods. Not less ugly either.

A 4th would be to use a class method sprintf() that replaces /%\.\df/ 
with F if necessary.



I think the constant is the best solution, it has to be prefixed 
though, e.g. FILE_PDF_FLOAT, but that would make a lot of ugly code. 
4) is probably the most elegant solution.
07/03/2006 05:41:26 PM thomas (at) gelf (dot) net Comment #3 Reply to this comment
You're right :-( They really did a GREAT job *grrrr*



So I would consider to either return an instance of one of two distinct

classes (PHP >=4.3.10+ & PHP5 vs PHP <4.3.9) or to otherwise define

a FLOAT_TYPE constant (= $version_old ? 'f' : 'F') to be used in all the

sprintf strings.



Both are really ugly solutions - as too often with PHP :-(



I personally don't care about PHP < 4.3.10 as I'm fortunately doing most

of my work on 5.1.x - but you're absolutely right, File_PDF has to do it's

work also for older PHP versions.



Do you consider one of my above suggestions viable?



Cheers,

Thomas Gelf
07/03/2006 05:03:20 PM Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
This is no viable solution unfortunately. Because not only the 
behaviour of sprintf() has changed, but the %F type specifier has only 
been added with PHP 4.3.10. But Horde needs to work with PHP 4.3, 
File_PDF even with 4.2.
06/29/2006 06:34:21 PM thomas (at) gelf (dot) net Comment #1
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
New Attachment: File_PDF-locales_bug.patch Download
Queue ⇒ Horde Framework Packages
Summary ⇒ File/PDF.php - Bug since PHP 4.3.10 with certain locales
Type ⇒ Bug
Reply to this comment
I really got angry about this one (angry about PHP - not Horde):



PHP's Changelog for 4.3.10 contains a little note about "Improved number

handling on non-English locales."



  -> http://de.php.net/release_4_3_10.php



A small example is probably better than lots of words, so have a look at

this small piece of code:



   <?php

   $float = 4.12;

   printf('%.2f <=> %.2F', $float, $float);

   setlocale(LC_ALL, 'de_DE.UTF-8');

   echo "\n";

   printf('%.2f <=> %.2F', $float, $float);

   ?>



And now have a look at it's output:



   4.12 <=> 4.12

   4,12 <=> 4.12



I really couldn't believe that this guys are able to do such intrusive changes

from one minor version to the next one... PHP is #*%#$~*!!!



It took me a lot of debugging to find out why File_PDF works in a stand-

alone script (without horde) and created "illegal" PDF files when called

from a Horde application.



I attached a little patch containing all the %f -> %F replacements and also

other two not so important fixes:



- use of undefined $style in addPage()

- "if ($font_family)" -> "if (isset($font_family))" - There should probably

    always be a font_family, so the appropiate NOTICE might never happen;

    but as while debugging I've seen it once I changed also this one



Regards,

Thomas Gelf

Saved Queries