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.

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

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.

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

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.

Yes, as you may know, thttpd is not a threaded web server.

Jeremy

I have the latest PHP build (4.3.2, 29-May-2003), running Apache 2 on Redhat 8.0, and I am still experiencing this bug. My configure line is as follows:

'./configure' '--with-apxs2=/usr/local/apache2/current/bin/apxs' '--with-mysql=/usr/local/mysql' '--with-zlib-dir=/usr/lib/' '--enable-versioning' '--enable-track-vars=yes' '--enable-url-includes' '--enable-sysvshm=yes' '--enable-sysvsem=yes' '--enable-ftp' '--with-config-file-path=/etc' '--with-gettext=/usr/local' '--with-gd' '--with-jpeg-dir=/usr/local/lib' '--with-imap=/usr/local/imap-2002c1' '--with-imap-ssl=/usr/local/openssl' '--with-pear' '--enable-gd-native-ttf' '--with-ttf' 

A print_r of the array returned by the function gives me something like this:
Array ( [0] => 1108521344 [1] => 138256048 [2] => -1073758568 [3] => 1075360060 [4] => 1108521360 [5] => 1108517584 [6] => -1073758536 [7] => 1107767671 )

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

ok I am getting these strange values, on php4.3.2 with apache 1.3.28. on redhat 7.2, with imagettfbbox

here is some example dump:

width -1073758320 : height -5379645430array(8) {
  [0]=>
  int(60)
  [1]=>
  int(-1073758256)
  [2]=>
  int(-1073758264)
  [3]=>
  int(1077688217)
  [4]=>
  int(48)
  [5]=>
  int(0)
  [6]=>
  int(11288)
  [7]=>
  int(1078099916)
}

here is a url that will reproduce:
http://test.earth.itomic.com/build_text_image.php?imgStr=PRODUCT%20SPOTLIGHT&fontSize=14&font=v5loxicar

the source is here:
http://test.earth.itomic.com/build_text_image.php.txt

If this has been fixed in CVS, is there a version that works? or is there one that will be coming soon?

as you will notice if you look at the example URL, it works fine. I compiled with the system library of GD, instead of the internal GD library. It now works fine.

I have had the same problems with PHP 5.0.2.

I have found fiddling with the ./configure parameters for ttf rendering when compiling PHP will help resolve some of the problems. However I still find that text looks distorted under Linux when compared to Mac

Clearly this is a multithreading kind of issue which still happens, it apparently is really difficult to use mutexes or simply write re-entrant code. Nevertheless for people getting this, just use, as a very dirty hack:

$size = ImageTTFBbox($fontsize, 0, $fontfile, $txt);
$try = 1;
while ($size[2] < 0 && $try < 10) $size = ImageTTFBbox($fontsize, 0, $fontfile, $txt);

et voila, $size should mostly be okay ;)