#22513 [Opn]: imagettfbbox() returning bogus array values
ID: 22513 User updated by: jeremy at nirvani dot net Reported By: jeremy at nirvani dot net Status: Open Bug Type: GD related Operating System: linux 2.4.19 PHP Version: 5CVS-2003-03-03 (dev) New Comment: Yes, as you may know, thttpd is not a threaded web server. Jeremy Previous Comments: [2003-03-03 13:33:51] [EMAIL PROTECTED] You may experience problems if you use freetype in threaded enviroment, since that library is not thread-safe. But that does not affect thttpd afaik. [2003-03-03 13:21:50] jeremy at nirvani dot net Without calculating what exactly it should show back, your example is probably correct (as my build does not work, so I don't know exactly). I have no idea why the build I am using is returning bogus data. Does it have something to do with using the thttpd sapi (I hope not) - as I would hope that the gd_functions were abstracted enough to not be interfered by a particular sapi implementation. I assume (as most bugs go) that if I were running this on Apache1, there would be no problem - because I have never seen this problem on apache1+php, but was shocked when it occured using thttpd+php. However, in theory, should this break with a particular sapi? I mean, what if this doesn't work with php-cgi or php, roxen, or apache2? Do we just say who cares, run apache1, or do we try and fix it? I can run anything else anyone needs me to to try and get to the bottom of this - just let me know. Back to what is expected: as the man page (http://php.net/imagettfbbox) says, those array elements from 0->7 are positions of the image (X,Y) at the corners - so the values I am getting are obviously wrong - and the ones you are getting are what I would expect to see. Any number over 1000 (positive or negative) would seem to indicate something wrong. If you look at the values in the page I posted, you will see some really strange numbers - almost like the pointers are getting printed, or something - but anything but the correct values. Jeremy [2003-03-03 13:07:59] [EMAIL PROTECTED] Can you show that is the 'expected' output of this function? On my system it returns array(8) { [0]=> int(-3) [1]=> int(1) [2]=> int(79) [3]=> int(1) [4]=> int(79) [5]=> int(-34) [6]=> int(-3) [7]=> int(-34) } But since no position for the text is provided the positioning is completely random. What matters is the difference between the various numbers, which you can use to determine the how much space the text will occupy. ---------------- [2003-03-03 11:29:35] jeremy at nirvani dot net BTW, this is NOT fixed in CVS or at least nothing was described as what was change in CVS that fixes this. I just did a cvs up and re-built (Mon Mar 3 17:22:49 UTC 2003). The same problems occur. Please see the description I posted earlier. In case I was not clear before, I am using the php5 branch. Thanks, Jeremy [2003-03-03 09:09:08] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22513 -- Edit this bug report at http://bugs.php.net/?id=22513&edit=1
#22513 [Fbk->Opn]: imagettfbbox() returning bogus array values
ID: 22513 User updated by: jeremy at nirvani dot net Reported By: jeremy at nirvani dot net -Status: Feedback +Status: Open Bug Type: GD related Operating System: linux 2.4.19 PHP Version: 5CVS-2003-03-03 (dev) New Comment: Without calculating what exactly it should show back, your example is probably correct (as my build does not work, so I don't know exactly). I have no idea why the build I am using is returning bogus data. Does it have something to do with using the thttpd sapi (I hope not) - as I would hope that the gd_functions were abstracted enough to not be interfered by a particular sapi implementation. I assume (as most bugs go) that if I were running this on Apache1, there would be no problem - because I have never seen this problem on apache1+php, but was shocked when it occured using thttpd+php. However, in theory, should this break with a particular sapi? I mean, what if this doesn't work with php-cgi or php, roxen, or apache2? Do we just say who cares, run apache1, or do we try and fix it? I can run anything else anyone needs me to to try and get to the bottom of this - just let me know. Back to what is expected: as the man page (http://php.net/imagettfbbox) says, those array elements from 0->7 are positions of the image (X,Y) at the corners - so the values I am getting are obviously wrong - and the ones you are getting are what I would expect to see. Any number over 1000 (positive or negative) would seem to indicate something wrong. If you look at the values in the page I posted, you will see some really strange numbers - almost like the pointers are getting printed, or something - but anything but the correct values. Jeremy Previous Comments: [2003-03-03 13:07:59] [EMAIL PROTECTED] Can you show that is the 'expected' output of this function? On my system it returns array(8) { [0]=> int(-3) [1]=> int(1) [2]=> int(79) [3]=> int(1) [4]=> int(79) [5]=> int(-34) [6]=> int(-3) [7]=> int(-34) } But since no position for the text is provided the positioning is completely random. What matters is the difference between the various numbers, which you can use to determine the how much space the text will occupy. ---------------- [2003-03-03 11:29:35] jeremy at nirvani dot net BTW, this is NOT fixed in CVS or at least nothing was described as what was change in CVS that fixes this. I just did a cvs up and re-built (Mon Mar 3 17:22:49 UTC 2003). The same problems occur. Please see the description I posted earlier. In case I was not clear before, I am using the php5 branch. Thanks, Jeremy [2003-03-03 09:09:08] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. ---------------- [2003-03-03 03:03:27] jeremy at nirvani dot net I have read these two bugs and this does not seem to be related: 17261 http://bugs.php.net/bug.php?id=17261 17192 http://bugs.php.net/bug.php?id=17192 To verify it is not one of the above bugs: (Notice only a big black box and no text) http://www.nirvani.org/not_bug_17192_or_17261.php http://www.nirvani.org/not_bug_17192_or_17261.phps To be sure, I even went so far as to put the GDFONRPATH in my global environment. (snip from phpinfo() _ENV["GDFONTPATH"] /home/httpd/clients/nirvani.org/ ) This shows the problem of the array elements having bogus values: http://www.nirvani.org/imagettfbbox_bug.php http://www.nirvani.org/imagettfbbox_bug.phps A strange oddity, refresh this above page and watch array[7] change - that should not happen, it should be the upper left corner, Y position, which IMO should stay the same, no matter how bogus the data is. fontfile (for sanity's sake): http://www.nirvani.org/times.ttf The array values returned seem to be a bug compared to what is expected from here: http://php.net/imagettfbbox Paste of the output array: array(8) { [0]=> int(5) [1]=> int(-1610627808) [2]=> int(-1610628216) [3]=> int(134958127) [4]=> int(136904992) [5]=> int(12) [6]=> int(-1610628152) [7]=> int(1075156968) } my configure line: './configure' '--disable-cli' '--disable-cgi&
#22513 [Csd->Opn]: imagettfbbox() returning bogus array values
ID: 22513 User updated by: jeremy at nirvani dot net Reported By: jeremy at nirvani dot net -Status: Closed +Status: Open Bug Type: GD related Operating System: linux 2.4.19 PHP Version: 5CVS-2003-03-03 (dev) New Comment: BTW, this is NOT fixed in CVS or at least nothing was described as what was change in CVS that fixes this. I just did a cvs up and re-built (Mon Mar 3 17:22:49 UTC 2003). The same problems occur. Please see the description I posted earlier. In case I was not clear before, I am using the php5 branch. Thanks, Jeremy Previous Comments: [2003-03-03 09:09:08] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-03-03 03:03:27] jeremy at nirvani dot net I have read these two bugs and this does not seem to be related: 17261 http://bugs.php.net/bug.php?id=17261 17192 http://bugs.php.net/bug.php?id=17192 To verify it is not one of the above bugs: (Notice only a big black box and no text) http://www.nirvani.org/not_bug_17192_or_17261.php http://www.nirvani.org/not_bug_17192_or_17261.phps To be sure, I even went so far as to put the GDFONRPATH in my global environment. (snip from phpinfo() _ENV["GDFONTPATH"] /home/httpd/clients/nirvani.org/ ) This shows the problem of the array elements having bogus values: http://www.nirvani.org/imagettfbbox_bug.php http://www.nirvani.org/imagettfbbox_bug.phps A strange oddity, refresh this above page and watch array[7] change - that should not happen, it should be the upper left corner, Y position, which IMO should stay the same, no matter how bogus the data is. fontfile (for sanity's sake): http://www.nirvani.org/times.ttf The array values returned seem to be a bug compared to what is expected from here: http://php.net/imagettfbbox Paste of the output array: array(8) { [0]=> int(5) [1]=> int(-1610627808) [2]=> int(-1610628216) [3]=> int(134958127) [4]=> int(136904992) [5]=> int(12) [6]=> int(-1610628152) [7]=> int(1075156968) } my configure line: './configure' '--disable-cli' '--disable-cgi' '--with-zlib' '--with-bz2' '--without-pear' '--with-gd' '--with-ttf' '--with-freetype' '--enable-gd-native-ttf' '--enable-bcmath' '--with-thttpd=/usr/src/thttpd-2.21b' phpinfo(): http://www.nirvani.org/php.html The same bug seemed to happend yesterday on a previous compile also. I added --with-ttf and --enable-gd-native-ttf, but that made no difference. Other GD stuff works. Looks like configure picked up on the bundled GD (2.0 compatible). It seems like anything GD-font-related does not work, and so this might be a deeper bug than just in imagettfbbox(). Jeremy -- Edit this bug report at http://bugs.php.net/?id=22513&edit=1
#22513 [NEW]: imagettfbbox() returning bogus array values
From: jeremy at nirvani dot net Operating system: linux 2.4.19 PHP version: 5CVS-2003-03-03 (dev) PHP Bug Type: GD related Bug description: imagettfbbox() returning bogus array values I have read these two bugs and this does not seem to be related: 17261 http://bugs.php.net/bug.php?id=17261 17192 http://bugs.php.net/bug.php?id=17192 To verify it is not one of the above bugs: (Notice only a big black box and no text) http://www.nirvani.org/not_bug_17192_or_17261.php http://www.nirvani.org/not_bug_17192_or_17261.phps To be sure, I even went so far as to put the GDFONRPATH in my global environment. (snip from phpinfo() _ENV["GDFONTPATH"] /home/httpd/clients/nirvani.org/ ) This shows the problem of the array elements having bogus values: http://www.nirvani.org/imagettfbbox_bug.php http://www.nirvani.org/imagettfbbox_bug.phps A strange oddity, refresh this above page and watch array[7] change - that should not happen, it should be the upper left corner, Y position, which IMO should stay the same, no matter how bogus the data is. fontfile (for sanity's sake): http://www.nirvani.org/times.ttf The array values returned seem to be a bug compared to what is expected from here: http://php.net/imagettfbbox Paste of the output array: array(8) { [0]=> int(5) [1]=> int(-1610627808) [2]=> int(-1610628216) [3]=> int(134958127) [4]=> int(136904992) [5]=> int(12) [6]=> int(-1610628152) [7]=> int(1075156968) } my configure line: './configure' '--disable-cli' '--disable-cgi' '--with-zlib' '--with-bz2' '--without-pear' '--with-gd' '--with-ttf' '--with-freetype' '--enable-gd-native-ttf' '--enable-bcmath' '--with-thttpd=/usr/src/thttpd-2.21b' phpinfo(): http://www.nirvani.org/php.html The same bug seemed to happend yesterday on a previous compile also. I added --with-ttf and --enable-gd-native-ttf, but that made no difference. Other GD stuff works. Looks like configure picked up on the bundled GD (2.0 compatible). It seems like anything GD-font-related does not work, and so this might be a deeper bug than just in imagettfbbox(). Jeremy -- Edit bug report at http://bugs.php.net/?id=22513&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22513&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22513&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22513&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22513&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22513&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22513&r=support Expected behavior: http://bugs.php.net/fix.php?id=22513&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22513&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22513&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22513&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22513&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22513&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22513&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22513&r=gnused