Bug #49869 [Com]: imagettfbbox returns bogus value

2010-07-30 Thread ken at smallboxcms dot com
Edit report at http://bugs.php.net/bug.php?id=49869&edit=1

 ID: 49869
 Comment by:     ken at smallboxcms dot com
 Reported by:orel at melix dot net
 Summary:imagettfbbox returns bogus value
 Status: Assigned
 Type:   Bug
 Package:GD related
 Operating System:   Linux
 PHP Version:5.2.11
 Assigned To:tabe
 Block user comment: N

 New Comment:

Got tired of being stuck at 5.2.9 while waiting for a fix for this bug.
Compiled PHP against the standard (non bundled) version of GD and all is
well. Using GD rpm version gd-devel-2.0.33


Previous Comments:

[2010-03-19 23:25:19] administrateur at exinsidephp dot com

See http://bugs.php.net/bug.php?id=51315



Problem isn't resolved.

Tested width the last snapshot (PHP 5.3.2)


[2010-01-26 01:00:02] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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".


[2010-01-18 09:36:42] t...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




[2009-11-04 15:05:50] orel at melix dot net

It is ok with PHP 5.3.2-dev

with this configure line

./configure  --with-gd --enable-gd-native-ttf  --with-freetype-dir



Result is

Array

(

[0] => -1

[1] => 3

[2] => 173

[3] => 3

[4] => 173

[5] => -14

[6] => -1

[7] => -14

)


[2009-10-29 03:30:31] t...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

It looks ok with PHP_5_3:

Array

(

[0] => -1

[1] => 3

[2] => 173

[3] => 3

[4] => 173

[5] => -14

[6] => -1

[7] => -14

)






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/bug.php?id=49869


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49869&edit=1


[PHP-BUG] Bug #52640 [NEW]: Odd Garbage collection Behaviour with Dom Node

2010-08-18 Thread ken at smallboxcms dot com
From: 
Operating system: Linux
PHP version:  5.3.3
Package:  DOM XML related
Bug Type: Bug
Bug description:Odd Garbage collection Behaviour with Dom Node

Description:

Variables added to dom nodes are later unset. This behaviour does not
appear to happen with other types of PHP objects. 

Test script:
---
doc = $doc;

$node = $doc->createElement('node');

$doc->appendChild($node);



$node->foo = true;



$obj = new stdClass;

$blah->obj = $obj;

$obj->child = new stdClass;

$obj->child->foo = true;

}



humbug();

echo "Should be set: ".$blah->doc->firstChild->foo."\n";

echo "Is Set: ".$blah->obj->child->foo."\n";



?>

Expected result:

I would expect that $blah->doc->firstChild->foo would be set after the
function call. 


-- 
Edit bug report at http://bugs.php.net/bug.php?id=52640&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52640&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52640&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52640&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52640&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52640&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52640&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52640&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52640&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52640&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52640&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52640&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52640&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52640&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52640&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52640&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52640&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52640&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52640&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52640&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52640&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52640&r=mysqlcfg



Req #24949 [Com]: Requesting nicer way of setting undefined variables to default val. ifsetor / ?:

2010-11-18 Thread ken at smallboxcms dot com
Edit report at http://bugs.php.net/bug.php?id=24949&edit=1

 ID: 24949
 Comment by:     ken at smallboxcms dot com
 Reported by:nickj-php at nickj dot org
 Summary:Requesting nicer way of setting undefined variables
 to default val. ifsetor / ?:
 Status: Closed
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:6
 Assigned To:jani
 Block user comment: N
 Private report: N

 New Comment:

I personally have never found a use for ?: and think at best it rarely
would solve the problem that ifsetor has been requested for. because ?:
throws a notice when the variable being tested for is undefined one is
still forced to use the longer sintax



$foo = isset($_REQUEST['name_of_really_long_variable']) ?
$_REQUEST['name_of_really_long_variable'] : null;



Hands down my biggest peeve with PHP



Also sadly there is no way to implement something in userland because
testing for a new element in an array has the unfortunate side effect of
also setting that element. Only solution is an operator that works like
isset or empty but has the potential to return the value of the variable
being tested for instead of true or false.


Previous Comments:

[2010-11-18 23:08:00] j...@php.net

?: exists since 5.3.


[2006-01-20 01:46:25] nickj-php at nickj dot org

That workaround works for most situations, but maybe not all, such as
for constants (which cannot be passed-by-reference):



$val = _ifsetor(null, 'some value');

$php_ver = _ifsetor(PHP_VERSION, 'some value');



However, I'm not sure whether such a thing should ideally work (i.e.
perhaps it's best that this doesn't work, but on the other hand I can't
see why it shouldn't) - so I'm honestly not sure.



The main point though is that it's a common requirement, especially for
web forms, to have to test for a set value, and supply a default if none
is set - so it could be good if the language core natively included this
functionality.



Happily, it looks like this is going to happen in PHP6. Please see:
http://www.php.net/~derick/meeting-notes.html#ifsetor-as-replacement-for-foo-isset-foo-foo-something-else
 (long URL, so may have wraparound issues).



The outcome was that PHP will get a new "?:" construct, like the one
mentioned previously by Xuefer. Personally, I realise now that this is a
far neater approach that having a function (such as
ifsetor/noUnset/default), so kudos to the PHP developers.


[2006-01-19 19:03:01] chris dot vigelius at gmx dot net

Workaround: You can implement the functionality using references



error_reporting (E_ALL);



function _ifsetor(&$field, $defaultvalue) {

return (isset($field))?$field:$defaultvalue;

}



$v1 = $v2 = 'x';

echo _ifsetor($v1, 'v1 is not set');

unset($v2);

echo _ifsetor($v2, 'v2 is not set');



This works in 5.1.2 without warnings (haven't checked other versions,
though)


[2005-01-02 02:42:02] nickj-php at nickj dot org

>From Derick Rethans PHP Look Back 2004
[http://www.derickrethans.nl/month-2004-12.php?item=20041231#20041231],
there were two discussions during the year on this topic on the PHP-DEV
mailing list, which I am adding links to here (as they help to summarize
various aspects of this) :

1) April 2004:
http://groups.google.com.au/groups?threadm=c5m94m$31k...@freebsd.csie.nctu.edu.tw

2) July 2004:
http://groups.google.com.au/groups?threadm=cci54b$t6...@freebsd.csie.nctu.edu.tw


[2003-10-09 18:45:32] marcus at deck16 dot com

I also came across that "problem" and voted for that "bug".



It is possible to write a function though. Just pass the var Name as a
string:








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/bug.php?id=24949


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=24949&edit=1


Bug #51315 [Com]: imagettfbbox randomly don't work

2010-11-22 Thread ken at smallboxcms dot com
Edit report at http://bugs.php.net/bug.php?id=51315&edit=1

 ID: 51315
 Comment by:     ken at smallboxcms dot com
 Reported by:administrateur at exinsidephp dot com
 Summary:imagettfbbox randomly don't work
 Status: Assigned
 Type:   Bug
 Package:GD related
 Operating System:   Debian GNU/Linux 5.0
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

I had this problem with the bundled version of GD in PHP 5.3.3. I am
pretty much stuck at 5.2.9 as that was the last version of PHP where
this bug did not happen.


Previous Comments:

[2010-11-03 12:47:04] paj...@php.net

@natan dot frei at gmail dot com



Please try using the bundled GD instead, in the meantime.


[2010-11-03 12:43:58] natan dot frei at gmail dot com

Debian Lenny

Linux v101.domain 2.6.26-2-openvz-686 #1 SMP Thu Sep 16 22:16:19 UTC
2010 i686 GNU/Linux

# dpkg -l | grep php

ii  libapache2-mod-php5 5.2.6.dfsg.1-1+lenny9   
server-side, HTML-embedded scripting languag

ii  php-pear5.2.6.dfsg.1-1+lenny9PEAR - PHP
Extension and Application Reposit

ii  php55.2.6.dfsg.1-1+lenny9   
server-side, HTML-embedded scripting languag

ii  php5-cli5.2.6.dfsg.1-1+lenny9   
command-line interpreter for the php5 script

ii  php5-common 5.2.6.dfsg.1-1+lenny9Common
files for packages built from the php

ii  php5-curl   5.2.6.dfsg.1-1+lenny9CURL module
for php5

ii  php5-gd 5.2.6.dfsg.1-1+lenny9GD module
for php5

ii  php5-suhosin0.9.27-1 advanced
protection module for php5



The same issue.

Sometimes imagettfbbox returns wrong value for x position.

For example:

-1,0,-2147483648,0,-2147483648,-12,-1,-12


[2010-08-03 09:46:43] administrateur at exinsidephp dot com

I have upgrade my server for install DotDeb package with PHP 5.3.3
(apt-get update && apt-get ugrade) and the problem have disapear with
this release.


[2010-07-17 20:50:47] geiss...@php.net

According to Sean, this appears to be a bug in libgd that has been fixed
in the 

copy included by PHP but not at upstream. I'm afraid I don't know any
other 

detail.

Pierre, could you please take a look at it? (and if possible, update
libgd 

upstream :)


[2010-05-01 17:29:47] geiss...@php.net

I tried with the following versions and with all of them the result is
the same:

4.1.2, 4.2.4, 4.3.4, 4.4.3



So it's a bug on libgd's side. Will ask Sean as he is the maintainer at
Debian.




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/bug.php?id=51315


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51315&edit=1


Bug #52640 [Bgs]: Odd Garbage collection Behaviour with Dom Node

2011-02-17 Thread ken at smallboxcms dot com
Edit report at http://bugs.php.net/bug.php?id=52640&edit=1

 ID: 52640
 User updated by:    ken at smallboxcms dot com
 Reported by:    ken at smallboxcms dot com
 Summary:Odd Garbage collection Behaviour with Dom Node
 Status: Bogus
 Type:   Bug
 Package:DOM XML related
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Well, to my way of thinking the the XML document is expressed as a PHP
object so it should behave as one in every respect. Here is an example
where there is a distinct difference in that behaviour, one that would
be unexpected by a PHP programmer who is not intimately acquainted with
PHP's internals. I am fairly certain that this difference is
undocumented. 



Here is another example which more clearly illustrates the problem. 



doc = $doc;

$node = $doc->createElement('node');

$doc->appendChild($node);



$node->foo = true;



$obj = new stdClass;

$blah->obj = $obj;

$obj->child = new stdClass;

$obj->child->foo = true;



echo "Why is this set: ".$blah->doc->firstChild->foo."";

}



humbug();

echo "When this is not set: ".$blah->doc->firstChild->foo."\n";

echo "This is Set: ".$blah->obj->child->foo."\n";







?>


Previous Comments:

[2011-02-17 22:56:39] rricha...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

DOM objects are just wrappers to underlying libxml2 structures and
unless directly 

referenced, i.e. $blah->node = $node, the $node object is no longer
referenced 

outside of the function. Appending the node appends the libxml2 node
structure to 

the underlying xml tree, does nothing in respect to the DOM object
wrapper.


[2010-08-19 00:32:30] ken at smallboxcms dot com

Description:

Variables added to dom nodes are later unset. This behaviour does not
appear to happen with other types of PHP objects. 

Test script:
---
doc = $doc;

$node = $doc->createElement('node');

$doc->appendChild($node);



$node->foo = true;



$obj = new stdClass;

$blah->obj = $obj;

$obj->child = new stdClass;

$obj->child->foo = true;

}



humbug();

echo "Should be set: ".$blah->doc->firstChild->foo."\n";

echo "Is Set: ".$blah->obj->child->foo."\n";



?>

Expected result:

I would expect that $blah->doc->firstChild->foo would be set after the
function call. 







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52640&edit=1