#22513 [Opn]: imagettfbbox() returning bogus array values

2003-03-03 Thread jeremy at nirvani dot net
 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 [Opn]: imagettfbbox() returning bogus array values

2003-03-03 Thread iliaa
 ID:   22513
 Updated by:   [EMAIL PROTECTED]
 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:

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.


Previous Comments:


[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.





[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]