|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22513 imagettfbbox() returning bogus array values
Submitted: 2003-03-03 03:03 UTC Modified: 2003-06-26 01:00 UTC
Avg. Score:4.1 ± 0.6
Reproduced:6 of 6 (100.0%)
Same Version:3 (50.0%)
Same OS:4 (66.7%)
From: jeremy at nirvani dot net Assigned:
Status: No Feedback Package: GD related
PHP Version: 5CVS-2003-03-03 (dev) OS: linux 2.4.19
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-03-03 03:03 UTC] jeremy at nirvani dot net
I have read these two bugs and this does not seem to be related: 

To verify it is not one of the above bugs:
(Notice only a big black box and no text)

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/ )

This shows the problem of the array elements having bogus values:

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):

The array values returned seem to be a bug compared to what is expected from here:

Paste of the output array:
array(8) {

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'


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().



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-03 09:09 UTC]
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
In case this was a documentation problem, the fix will show up soon at

In case this was a website problem, the change will show
up on the site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.

 [2003-03-03 11:29 UTC] 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.

 [2003-03-03 13:07 UTC]
Can you show that is the 'expected' output of this function?

On my system it returns
array(8) {

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 13:21 UTC] 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 ( 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.

 [2003-03-03 13:33 UTC]
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:36 UTC] jeremy at nirvani dot net
Yes, as you may know, thttpd is not a threaded web server.

 [2003-06-03 10:06 UTC] veronique at talafone dot com
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 )
 [2003-06-26 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2003-08-08 06:33 UTC] nick at itomic dot com
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) {

here is a url that will reproduce:

the source is here:

If this has been fixed in CVS, is there a version that works? or is there one that will be coming soon?
 [2003-08-10 21:35 UTC] nick at itomic dot com
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.
 [2004-11-16 18:45 UTC] Jason at amp-design dot net
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
 [2008-10-30 11:13 UTC] jeroen at unfix dot org
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 ;)
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu May 23 15:01:32 2019 UTC