#41803 [Fbk-Opn]: Linking MySQLi fails during ./configure
ID: 41803 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac 10.4.9 PHP Version: 5CVS-2007-06-25 (snap) New Comment: I deleted the entire directory and reinstalled from the .tar.gz snapshot. I still get the error, but the config.log is different (according to diff). It's uploaded to the same address. That looks like the error I'm getting. What command can I use to test it out? Previous Comments: [2007-06-26 10:51:05] [EMAIL PROTECTED] Perhaps this is the issue here: http://www.fatmixx.com/2007/05/30/ruby-mysql-gem-error/ [2007-06-26 10:43:16] [EMAIL PROTECTED] That config.log is identical to what I get for succesful run. Just to be sure: You're using 100% fresh sources, ie. you have deleted config.cache before rerunning configure? [2007-06-26 03:08:19] seth at pricepages dot org Here it is in its entirety: http://144.92.10.211/config.log [2007-06-25 23:29:50] [EMAIL PROTECTED] What does config.log have about this? [2007-06-25 22:36:59] seth at pricepages dot org $ ls -l /usr/local/mysql/lib/libmysqlclient.15.dylib -rwxr-xr-x 1 root mysql 2033452 Apr 26 15:48 /usr/local/mysql/lib/ libmysqlclient.15.dylib $ ls -l /usr/local/mysql/lib/mysql/ ls: /usr/local/mysql/lib/mysql/: No such file or directory 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/41803 -- Edit this bug report at http://bugs.php.net/?id=41803edit=1
#41803 [Bgs]: Linking MySQLi fails during ./configure
ID: 41803 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Bogus Bug Type: Compile Failure Operating System: Mac 10.4.9 PHP Version: 5CVS-2007-06-25 (snap) New Comment: Here's the bug report on MySQL's tracker: http://bugs.mysql.com/bug.php?id=28544 Previous Comments: [2007-06-26 14:24:39] [EMAIL PROTECTED] This has some more info (in german, but has english comments in the end): http://blog.calganx.net/2007/05/20/apache-2-php-5-und-mysql-5-fr-macos-x/ As this is really not PHP bug at all, I'm closing this. [2007-06-26 13:31:46] seth at pricepages dot org I deleted the entire directory and reinstalled from the .tar.gz snapshot. I still get the error, but the config.log is different (according to diff). It's uploaded to the same address. That looks like the error I'm getting. What command can I use to test it out? [2007-06-26 10:51:05] [EMAIL PROTECTED] Perhaps this is the issue here: http://www.fatmixx.com/2007/05/30/ruby-mysql-gem-error/ [2007-06-26 10:43:16] [EMAIL PROTECTED] That config.log is identical to what I get for succesful run. Just to be sure: You're using 100% fresh sources, ie. you have deleted config.cache before rerunning configure? [2007-06-26 03:08:19] seth at pricepages dot org Here it is in its entirety: http://144.92.10.211/config.log 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/41803 -- Edit this bug report at http://bugs.php.net/?id=41803edit=1
#41803 [NEW]: Linking MySQLi fails during ./configure
From: seth at pricepages dot org Operating system: Mac 10.4.9 PHP version: 5CVS-2007-06-25 (snap) PHP Bug Type: Compile Failure Bug description: Linking MySQLi fails during ./configure Description: The test program compiled by configure links to a non-existant mysqli library (and fails to be run). See the following debug.log: CONFIGURE: './configure' '--with-mysqli=/usr/local/mysql/bin/ mysql_config' CC: gcc CFLAGS: -I/usr/local/include -g -O2 CPPFLAGS:-no-cpp-precomp CXX: CXXFLAGS: INCLUDES:-I/usr/include/libxml2 -I/usr/local/php/ php5.2-200706251630/ext/date/lib -I/usr/local/mysql/include LDFLAGS:-liconv -L/usr/local/lib -L/usr/local/lib -L/usr/local/ lib -L/usr/local/mysql/lib -L/usr/local/mysql/lib LIBS: -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lmysqlclient -lz -lm -lxml2 -lz -liconv -lm DLIBS: SAPI: cgi PHP_RPATHS: /usr/local/lib /usr/local/mysql/lib uname -a: Darwin Pine06.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc gcc -o conftest -I/usr/local/include -g -O2 -no-cpp-precomp -liconv - L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/mysql/ lib -L/usr/local/mysql/lib conftest.c -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lmysqlclient -lz -lm -lxml2 -lz -liconv - lm 15 conftest.c: In function 'main': conftest.c:3: warning: incompatible implicit declaration of built-in function 'exit' dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient. 15.dylib Referenced from: /usr/local/php/php5.2-200706251630/./conftest Reason: image not found ./configure: line 90558: 4955 Trace/BPT trap ./conftest The dyld *does* exist at this location: /usr/local/mysql/lib/libmysqlclient.15.dylib mysql_config gives this: Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] Options: --cflags [-I/usr/local/mysql/include -Os -arch ppc - fno-common] --include[-I/usr/local/mysql/include] --libs [-L/usr/local/mysql/lib -lmysqlclient -lz - lm] --libs_r [-L/usr/local/mysql/lib -lmysqlclient_r -lz - lm] --socket [/tmp/mysql.sock] --port [3306] --version[5.0.41] --libmysqld-libs [-L/usr/local/mysql/lib -lmysqld -lz -lm] This problem exists in the latest v5 CVS snap and 5.2.3, but not in 5.2.0. Reproduce code: --- ./configure --with-mysqli=/usr/local/mysql/bin/mysql_config Expected result: Configure should end like this: ... | your web space, users may be able to circumvent existing .htaccess | | security by loading files directly through the parser. See| | http://www.php.net/manual/security.php for more details. | ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | ... Actual result: -- But it doesn't: ... | your web space, users may be able to circumvent existing .htaccess | | security by loading files directly through the parser. See| | http://www.php.net/manual/security.php for more details. | ++ | *** ATTENTION ***| || | Something is likely to be messed up here, because the configure| | script was not able to detect a simple feature on your platform. | | This is often caused by incorrect configuration parameters. Please | | see the file debug.log for error messages. | || | If you are unable to fix this, send the file debug.log to the | | [EMAIL PROTECTED] mailing list and include appropiate | | information about your setup. | ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | ... -- Edit bug report at http://bugs.php.net/?id=41803edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41803r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41803r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41803r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41803r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41803r=alreadyfixed Need backtrace: http
#41803 [Fbk-Opn]: Linking MySQLi fails during ./configure
ID: 41803 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac 10.4.9 PHP Version: 5CVS-2007-06-25 (snap) New Comment: No, the library is in /usr/local/mysql/lib and mysql_config beleives it is in /usr/local/mysql/lib. I'm not sure what is causing the conftest program to do what it's doing. The mysql install was a binary install of v5.0.41, and as far as I can tell is working fine. Previous Comments: [2007-06-25 20:43:24] [EMAIL PROTECTED] According to your mysql_config output, the library should be in: /usr/local/mysql/lib/ And you say the library is in: /usr/local/mysql/lib/mysql/ Have you moved it manually or something? [2007-06-25 17:27:51] seth at pricepages dot org Description: The test program compiled by configure links to a non-existant mysqli library (and fails to be run). See the following debug.log: CONFIGURE: './configure' '--with-mysqli=/usr/local/mysql/bin/ mysql_config' CC: gcc CFLAGS: -I/usr/local/include -g -O2 CPPFLAGS:-no-cpp-precomp CXX: CXXFLAGS: INCLUDES:-I/usr/include/libxml2 -I/usr/local/php/ php5.2-200706251630/ext/date/lib -I/usr/local/mysql/include LDFLAGS:-liconv -L/usr/local/lib -L/usr/local/lib -L/usr/local/ lib -L/usr/local/mysql/lib -L/usr/local/mysql/lib LIBS: -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lmysqlclient -lz -lm -lxml2 -lz -liconv -lm DLIBS: SAPI: cgi PHP_RPATHS: /usr/local/lib /usr/local/mysql/lib uname -a: Darwin Pine06.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc gcc -o conftest -I/usr/local/include -g -O2 -no-cpp-precomp -liconv - L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/mysql/ lib -L/usr/local/mysql/lib conftest.c -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lmysqlclient -lz -lm -lxml2 -lz -liconv - lm 15 conftest.c: In function 'main': conftest.c:3: warning: incompatible implicit declaration of built-in function 'exit' dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient. 15.dylib Referenced from: /usr/local/php/php5.2-200706251630/./conftest Reason: image not found ./configure: line 90558: 4955 Trace/BPT trap ./conftest The dyld *does* exist at this location: /usr/local/mysql/lib/libmysqlclient.15.dylib mysql_config gives this: Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] Options: --cflags [-I/usr/local/mysql/include -Os -arch ppc - fno-common] --include[-I/usr/local/mysql/include] --libs [-L/usr/local/mysql/lib -lmysqlclient -lz - lm] --libs_r [-L/usr/local/mysql/lib -lmysqlclient_r -lz - lm] --socket [/tmp/mysql.sock] --port [3306] --version[5.0.41] --libmysqld-libs [-L/usr/local/mysql/lib -lmysqld -lz -lm] This problem exists in the latest v5 CVS snap and 5.2.3, but not in 5.2.0. Reproduce code: --- ./configure --with-mysqli=/usr/local/mysql/bin/mysql_config Expected result: Configure should end like this: ... | your web space, users may be able to circumvent existing .htaccess | | security by loading files directly through the parser. See| | http://www.php.net/manual/security.php for more details. | ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | ... Actual result: -- But it doesn't: ... | your web space, users may be able to circumvent existing .htaccess | | security by loading files directly through the parser. See| | http://www.php.net/manual/security.php for more details. | ++ | *** ATTENTION ***| || | Something is likely to be messed up here, because the configure| | script was not able to detect a simple feature on your platform. | | This is often caused by incorrect configuration parameters. Please | | see the file debug.log for error messages. | || | If you are unable to fix this, send the file debug.log to the | | [EMAIL PROTECTED] mailing list and include appropiate | | information about your setup
#41803 [Fbk-Opn]: Linking MySQLi fails during ./configure
ID: 41803 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac 10.4.9 PHP Version: 5CVS-2007-06-25 (snap) New Comment: $ ls -l /usr/local/mysql/lib/libmysqlclient.15.dylib -rwxr-xr-x 1 root mysql 2033452 Apr 26 15:48 /usr/local/mysql/lib/ libmysqlclient.15.dylib $ ls -l /usr/local/mysql/lib/mysql/ ls: /usr/local/mysql/lib/mysql/: No such file or directory Previous Comments: [2007-06-25 21:45:47] [EMAIL PROTECTED] ls -l /usr/local/mysql/lib/libmysqlclient.15.dylib ? [2007-06-25 21:28:42] seth at pricepages dot org No, the library is in /usr/local/mysql/lib and mysql_config beleives it is in /usr/local/mysql/lib. I'm not sure what is causing the conftest program to do what it's doing. The mysql install was a binary install of v5.0.41, and as far as I can tell is working fine. [2007-06-25 20:43:24] [EMAIL PROTECTED] According to your mysql_config output, the library should be in: /usr/local/mysql/lib/ And you say the library is in: /usr/local/mysql/lib/mysql/ Have you moved it manually or something? [2007-06-25 17:27:51] seth at pricepages dot org Description: The test program compiled by configure links to a non-existant mysqli library (and fails to be run). See the following debug.log: CONFIGURE: './configure' '--with-mysqli=/usr/local/mysql/bin/ mysql_config' CC: gcc CFLAGS: -I/usr/local/include -g -O2 CPPFLAGS:-no-cpp-precomp CXX: CXXFLAGS: INCLUDES:-I/usr/include/libxml2 -I/usr/local/php/ php5.2-200706251630/ext/date/lib -I/usr/local/mysql/include LDFLAGS:-liconv -L/usr/local/lib -L/usr/local/lib -L/usr/local/ lib -L/usr/local/mysql/lib -L/usr/local/mysql/lib LIBS: -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lmysqlclient -lz -lm -lxml2 -lz -liconv -lm DLIBS: SAPI: cgi PHP_RPATHS: /usr/local/lib /usr/local/mysql/lib uname -a: Darwin Pine06.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc gcc -o conftest -I/usr/local/include -g -O2 -no-cpp-precomp -liconv - L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/mysql/ lib -L/usr/local/mysql/lib conftest.c -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lmysqlclient -lz -lm -lxml2 -lz -liconv - lm 15 conftest.c: In function 'main': conftest.c:3: warning: incompatible implicit declaration of built-in function 'exit' dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient. 15.dylib Referenced from: /usr/local/php/php5.2-200706251630/./conftest Reason: image not found ./configure: line 90558: 4955 Trace/BPT trap ./conftest The dyld *does* exist at this location: /usr/local/mysql/lib/libmysqlclient.15.dylib mysql_config gives this: Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] Options: --cflags [-I/usr/local/mysql/include -Os -arch ppc - fno-common] --include[-I/usr/local/mysql/include] --libs [-L/usr/local/mysql/lib -lmysqlclient -lz - lm] --libs_r [-L/usr/local/mysql/lib -lmysqlclient_r -lz - lm] --socket [/tmp/mysql.sock] --port [3306] --version[5.0.41] --libmysqld-libs [-L/usr/local/mysql/lib -lmysqld -lz -lm] This problem exists in the latest v5 CVS snap and 5.2.3, but not in 5.2.0. Reproduce code: --- ./configure --with-mysqli=/usr/local/mysql/bin/mysql_config Expected result: Configure should end like this: ... | your web space, users may be able to circumvent existing .htaccess | | security by loading files directly through the parser. See| | http://www.php.net/manual/security.php for more details. | ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | ... Actual result: -- But it doesn't: ... | your web space, users may be able to circumvent existing .htaccess | | security by loading files directly through the parser. See| | http://www.php.net/manual/security.php for more details. | ++ | *** ATTENTION
#41803 [Fbk-Opn]: Linking MySQLi fails during ./configure
ID: 41803 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac 10.4.9 PHP Version: 5CVS-2007-06-25 (snap) New Comment: Here it is in its entirety: http://144.92.10.211/config.log Previous Comments: [2007-06-25 23:29:50] [EMAIL PROTECTED] What does config.log have about this? [2007-06-25 22:36:59] seth at pricepages dot org $ ls -l /usr/local/mysql/lib/libmysqlclient.15.dylib -rwxr-xr-x 1 root mysql 2033452 Apr 26 15:48 /usr/local/mysql/lib/ libmysqlclient.15.dylib $ ls -l /usr/local/mysql/lib/mysql/ ls: /usr/local/mysql/lib/mysql/: No such file or directory [2007-06-25 21:45:47] [EMAIL PROTECTED] ls -l /usr/local/mysql/lib/libmysqlclient.15.dylib ? [2007-06-25 21:28:42] seth at pricepages dot org No, the library is in /usr/local/mysql/lib and mysql_config beleives it is in /usr/local/mysql/lib. I'm not sure what is causing the conftest program to do what it's doing. The mysql install was a binary install of v5.0.41, and as far as I can tell is working fine. [2007-06-25 20:43:24] [EMAIL PROTECTED] According to your mysql_config output, the library should be in: /usr/local/mysql/lib/ And you say the library is in: /usr/local/mysql/lib/mysql/ Have you moved it manually or something? 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/41803 -- Edit this bug report at http://bugs.php.net/?id=41803edit=1
#40572 [Fbk-Opn]: Alpha composite allows color to bleed through
ID: 40572
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5.2.1
Assigned To: pajoye
New Comment:
Well, I ran the following code against the newly released C
library, and things seem to work as expected. GD 2.0.33 seg
faults for some reason, but 2.0.34 fixes that. So, the bug
will be fixed when you sync with PHP's code?
gdImagePtr img;
int trans, pTrans;
FILE *fp;
img = gdImageCreateTrueColor(100, 100);
gdImageAlphaBlending(img, 1);
trans = gdImageColorResolveAlpha(img,255,0,0, 127);
gdImageFill(img, 0,0, trans);
pTrans = gdImageColorResolveAlpha(img, 0,0,0, 64);
gdImageFilledRectangle(img, 10, 10, 50, 50, pTrans);
gdImageAlphaBlending(img, 0);
gdImageSaveAlpha(img,1);
fp = fopen(test.png, w);
gdImagePng(img, fp);
fclose(fp);
gdImageDestroy(img);
Previous Comments:
[2007-02-21 10:03:06] [EMAIL PROTECTED]
imagefill does not care about alpha blending but when you use a tiled
color (as it is actually an image/pattern filling).
$trans = imagecolorresolvealpha($img,255,0,0, 127);
Will always fill the area with red and a 100% transparent alpha.
imagealphablending($img, true); enables the blending mode. Set it to
false will store the alpha in the image.
You set it to true, that's why you get a red/black rectangle instead
of a gray semi transparent area.
However I agree that the behavior is not user friendly. The GD 2.0.34
behaves differently in a more logic way when the dst pixel is either
fully transparent or opaque.
OS X Fink already have 2.0.34, you can try to compile php against it.
Or you can see the different implementation in the GD sources (function
gdAlphaBlend):
http://cvs.php.net/viewvc.cgi/gd/libgd/gd.c
I will try to sync php gdAlphaBlend as soon as possible. I have to
check that it will not break BC in one way or another (I do not think
it will, but still need to test).
Do you get what you expect using the 2.0.34's gdAlphaBlend?
[2007-02-21 05:01:04] seth at pricepages dot org
Description:
I am filling the background of an image with a transparent red
(it shouldn't have an effect on the rest of the drawing). Over
it, I'm drawing a black, semi-transparent, square.
Reproduce code:
---
$img = imagecreatetruecolor(100, 100);
imagealphablending($img, true);
$trans = imagecolorresolvealpha($img,255,0,0, 127);
imagefill($img, 0,0, $trans);
$pTrans = imagecolorresolvealpha($img, 0,0,0, 64);
imagefilledrectangle($img, 10, 10, 50, 50, $pTrans);
imagealphablending($img, false);
imagesavealpha($img,true);
header('Content-Type: image/png');
imagepng($img);
Expected result:
I would expect the resulting image to be 100% transparent,
except for a grey, 50% transparent square.
Actual result:
--
Instead, the black is mixed with the red to form a dark-red
semi-transparent square. The red color should not be there,
because it was 100% transparent.
--
Edit this bug report at http://bugs.php.net/?id=40572edit=1
#40601 [NEW]: imagesavealpha() has opposite effect on transparent color
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5.2.1
PHP Bug Type: GD related
Bug description: imagesavealpha() has opposite effect on transparent color
Description:
The function imagesavealpha() has an opposite effect on the
output image if the color is marked as transparent. For
example, the code below should always create a clear image.
But it renders as black.
The interesting thing is that if you remove the imagesavealpha
, the image renders as expected (clear).
Reproduce code:
---
?php
$img = imagecreatetruecolor(100,100);
$trans = imagecolorresolve($img,0,0,0);
imagecolortransparent($img, $trans);
imagealphablending($img, false);
imagefilledrectangle($img, 0,0, 100,100, $trans);
//Has opposite affect
imagesavealpha($img,true);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
nothing (a clear image)
Actual result:
--
a solid black image
--
Edit bug report at http://bugs.php.net/?id=40601edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40601r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40601r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40601r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40601r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40601r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40601r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40601r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40601r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40601r=support
Expected behavior:http://bugs.php.net/fix.php?id=40601r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40601r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40601r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40601r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40601r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40601r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40601r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40601r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40601r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40601r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40601r=mysqlcfg
#40572 [NEW]: Alpha composite allows color to bleed through
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5.2.1
PHP Bug Type: GD related
Bug description: Alpha composite allows color to bleed through
Description:
I am filling the background of an image with a transparent red
(it shouldn't have an effect on the rest of the drawing). Over
it, I'm drawing a black, semi-transparent, square.
Reproduce code:
---
$img = imagecreatetruecolor(100, 100);
imagealphablending($img, true);
$trans = imagecolorresolvealpha($img,255,0,0, 127);
imagefill($img, 0,0, $trans);
$pTrans = imagecolorresolvealpha($img, 0,0,0, 64);
imagefilledrectangle($img, 10, 10, 50, 50, $pTrans);
imagealphablending($img, false);
imagesavealpha($img,true);
header('Content-Type: image/png');
imagepng($img);
Expected result:
I would expect the resulting image to be 100% transparent,
except for a grey, 50% transparent square.
Actual result:
--
Instead, the black is mixed with the red to form a dark-red
semi-transparent square. The red color should not be there,
because it was 100% transparent.
--
Edit bug report at http://bugs.php.net/?id=40572edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40572r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40572r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40572r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40572r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40572r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40572r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40572r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40572r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40572r=support
Expected behavior:http://bugs.php.net/fix.php?id=40572r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40572r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40572r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40572r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40572r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40572r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40572r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40572r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40572r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40572r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40572r=mysqlcfg
#39353 [Fbk-Opn]: more imagecopyresized() alpha problems
ID: 39353
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
I thought that a color with alpha = 127 will produce the
same results as a color marked as transparent. I want the
contents of $small to overwrite everything in $img. This is
not correct?
The bug#1 and bug#2 that I wrote were not intended to be
links, they were just supposed to show that I believe there
are two bugs at work here. This web site turned them into
links.
To reproduce the second bug without changing the first,
alter my code to look like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW, $srcH);
...
The background is supposed to be transparent, but where
$small has partial transparency, $img becomes fully opaque.
The final image should have partial transparency around the
object, but it does not.
Previous Comments:
[2006-11-04 15:52:11] [EMAIL PROTECTED]
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.
The transparent color has nothing to do with the *alpha* channel of any
other pixels.
The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.
Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?
As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.
Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo truecolor image\n;
} else {
$c = imagecolortransparent($small);
echo transparent index: . $c . \n;
print_r( imagecolorsforindex($small,$c));
}
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png
Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] = 246
[green] = 246
[blue] = 246
[alpha] = 127
)
Is it more clear now?
[2006-11-04 00:28:54] seth at pricepages dot org
Well, you can tell me what I'm doing wrong then. I have a
source image with fully transparent pixels. I would like to
copy it over another image, so the final image has fully
transparent pixels.
To do this, I set imagealphablending() to false, and I copy
via imagecopyresized(). But no fully transparent pixels are
copied.
Your statement does not address the second bug that I
mentioned.
[2006-11-04 00:17:25] [EMAIL PROTECTED]
But if the alpha blending is set to false, you want to copy
the transparent pixels.
No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.
I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.
[2006-11-03 00:23:48] seth at pricepages dot org
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
tmp = gdImageGetPixel (src, x, y);
if (gdImageGetTransparent (src) == tmp) {
tox += stx[x - srcX];
continue;
}
But if the alpha blending is set to false, you want to copy
the transparent pixels. So commenting out this if statement
removes one bug. There is other similar code in this loop,
so maybe it should all be removed?
Unfortunately, all result pixels still opaque, when the
source image pixels are partially transparent. So this code
does not fix the problem.
Reproduce code:
---
?php
$small = imagecreatefrompng(
'http
#39353 [Opn]: more imagecopyresized() alpha problems
ID: 39353
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
Status: Open
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
Also, if you alter the transparency of a color to be 64, and
you fill the image with that color, shouldn't the final
image have a transparency of 64?
imagecolorsforindex() gives the correct alpha value, but the
true color PNG produced in my browser has no partial
transparency. (it is all opaque)
The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
/*
var_dump(imagecolorsforindex($img, imagecolorat($img,
0,0)));
exit;
//*/
header('Content-Type: image/png');
...
Previous Comments:
[2006-11-04 17:01:40] seth at pricepages dot org
I thought that a color with alpha = 127 will produce the
same results as a color marked as transparent. I want the
contents of $small to overwrite everything in $img. This is
not correct?
The bug#1 and bug#2 that I wrote were not intended to be
links, they were just supposed to show that I believe there
are two bugs at work here. This web site turned them into
links.
To reproduce the second bug without changing the first,
alter my code to look like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW, $srcH);
...
The background is supposed to be transparent, but where
$small has partial transparency, $img becomes fully opaque.
The final image should have partial transparency around the
object, but it does not.
[2006-11-04 15:52:11] [EMAIL PROTECTED]
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.
The transparent color has nothing to do with the *alpha* channel of any
other pixels.
The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.
Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?
As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.
Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo truecolor image\n;
} else {
$c = imagecolortransparent($small);
echo transparent index: . $c . \n;
print_r( imagecolorsforindex($small,$c));
}
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png
Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] = 246
[green] = 246
[blue] = 246
[alpha] = 127
)
Is it more clear now?
[2006-11-04 00:28:54] seth at pricepages dot org
Well, you can tell me what I'm doing wrong then. I have a
source image with fully transparent pixels. I would like to
copy it over another image, so the final image has fully
transparent pixels.
To do this, I set imagealphablending() to false, and I copy
via imagecopyresized(). But no fully transparent pixels are
copied.
Your statement does not address the second bug that I
mentioned.
[2006-11-04 00:17:25] [EMAIL PROTECTED]
But if the alpha blending is set to false, you want to copy
the transparent pixels.
No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.
I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.
[2006-11-03 00:23:48] seth at pricepages dot org
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha
#39353 [Fbk-Opn]: more imagecopyresized() alpha problems
ID: 39353
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
I am simply trying to enlarge the original image. I can't find
a work-around in PHP, but I can create the image in Adobe
Photoshop.
This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png
By the way, this image is the outline of Bermuda. :)
Previous Comments:
[2006-11-04 17:42:49] [EMAIL PROTECTED]
Another thing you may not know is how to preserve the alpha channel
information on save:
http://blog.thepimp.net/misc/bug39353_with_alpha.png
you have to use imagesavealpha($img,true); before calling imagepng.
[2006-11-04 17:26:18] [EMAIL PROTECTED]
I thought that a color with alpha = 127 will produce the
same results as a color marked as transparent. I want the
contents of $small to overwrite everything in $img. This is
not correct?
But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.
http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?
If not, provide an image to show what you expect.
[2006-11-04 17:11:55] seth at pricepages dot org
Also, if you alter the transparency of a color to be 64, and
you fill the image with that color, shouldn't the final
image have a transparency of 64?
imagecolorsforindex() gives the correct alpha value, but the
true color PNG produced in my browser has no partial
transparency. (it is all opaque)
The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
/*
var_dump(imagecolorsforindex($img, imagecolorat($img,
0,0)));
exit;
//*/
header('Content-Type: image/png');
...
[2006-11-04 17:01:40] seth at pricepages dot org
I thought that a color with alpha = 127 will produce the
same results as a color marked as transparent. I want the
contents of $small to overwrite everything in $img. This is
not correct?
The bug#1 and bug#2 that I wrote were not intended to be
links, they were just supposed to show that I believe there
are two bugs at work here. This web site turned them into
links.
To reproduce the second bug without changing the first,
alter my code to look like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW, $srcH);
...
The background is supposed to be transparent, but where
$small has partial transparency, $img becomes fully opaque.
The final image should have partial transparency around the
object, but it does not.
[2006-11-04 15:52:11] [EMAIL PROTECTED]
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.
The transparent color has nothing to do with the *alpha* channel of any
other pixels.
The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.
Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?
As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.
Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo truecolor image\n;
} else {
$c = imagecolortransparent($small);
echo transparent index: . $c . \n;
print_r( imagecolorsforindex($small,$c));
}
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png
Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] = 246
[green] = 246
[blue] = 246
#39353 [Opn]: more imagecopyresized() alpha problems
ID: 39353
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
Status: Open
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
Oh! No, I didn't realize imagesavealpha() existed. Why is
saving the alpha a separate function? Shouldn't it be default?
Previous Comments:
[2006-11-04 17:45:05] seth at pricepages dot org
I am simply trying to enlarge the original image. I can't find
a work-around in PHP, but I can create the image in Adobe
Photoshop.
This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png
By the way, this image is the outline of Bermuda. :)
[2006-11-04 17:42:49] [EMAIL PROTECTED]
Another thing you may not know is how to preserve the alpha channel
information on save:
http://blog.thepimp.net/misc/bug39353_with_alpha.png
you have to use imagesavealpha($img,true); before calling imagepng.
[2006-11-04 17:26:18] [EMAIL PROTECTED]
I thought that a color with alpha = 127 will produce the
same results as a color marked as transparent. I want the
contents of $small to overwrite everything in $img. This is
not correct?
But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.
http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?
If not, provide an image to show what you expect.
[2006-11-04 17:11:55] seth at pricepages dot org
Also, if you alter the transparency of a color to be 64, and
you fill the image with that color, shouldn't the final
image have a transparency of 64?
imagecolorsforindex() gives the correct alpha value, but the
true color PNG produced in my browser has no partial
transparency. (it is all opaque)
The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
/*
var_dump(imagecolorsforindex($img, imagecolorat($img,
0,0)));
exit;
//*/
header('Content-Type: image/png');
...
[2006-11-04 17:01:40] seth at pricepages dot org
I thought that a color with alpha = 127 will produce the
same results as a color marked as transparent. I want the
contents of $small to overwrite everything in $img. This is
not correct?
The bug#1 and bug#2 that I wrote were not intended to be
links, they were just supposed to show that I believe there
are two bugs at work here. This web site turned them into
links.
To reproduce the second bug without changing the first,
alter my code to look like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW, $srcH);
...
The background is supposed to be transparent, but where
$small has partial transparency, $img becomes fully opaque.
The final image should have partial transparency around the
object, but it does not.
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/39353
--
Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39353 [Bgs]: more imagecopyresized() alpha problems
ID: 39353 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Bogus Bug Type: GD related Operating System: Mac 10.4 PHP Version: 5CVS-2006-11-02 (snap) Assigned To: pajoye New Comment: But I *still* can't produce the image that I want. I simply want to enlarge $small. How can I do this? Previous Comments: [2006-11-04 17:50:39] [EMAIL PROTECTED] Shouldn't it be default? Backward compatibility... GD is an old library. But things are getting better. No bug bogus. [2006-11-04 17:48:46] seth at pricepages dot org Oh! No, I didn't realize imagesavealpha() existed. Why is saving the alpha a separate function? Shouldn't it be default? [2006-11-04 17:45:05] seth at pricepages dot org I am simply trying to enlarge the original image. I can't find a work-around in PHP, but I can create the image in Adobe Photoshop. This is what I'm attempting to create: http://pricepages.org/temp/partialTrans2.png By the way, this image is the outline of Bermuda. :) [2006-11-04 17:42:49] [EMAIL PROTECTED] Another thing you may not know is how to preserve the alpha channel information on save: http://blog.thepimp.net/misc/bug39353_with_alpha.png you have to use imagesavealpha($img,true); before calling imagepng. [2006-11-04 17:26:18] [EMAIL PROTECTED] I thought that a color with alpha = 127 will produce the same results as a color marked as transparent. I want the contents of $small to overwrite everything in $img. This is not correct? But this color (imagecolortransparent($small)) *IS* the transparent color and is ignored on copy. http://blog.thepimp.net/misc/bug39353_out.png is it not what you expect? If not, provide an image to show what you expect. 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/39353 -- Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39353 [Bgs]: more imagecopyresized() alpha problems
ID: 39353 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Bogus Bug Type: GD related Operating System: Mac 10.4 PHP Version: 5CVS-2006-11-02 (snap) Assigned To: pajoye New Comment: That is a workaround. imagecopyresized() isn't working as defined in the manual, so you've changed the destination image to compensate. I suppose it's fine if you don't want to fix it, I think I can use this workaround for now. There is a waste of pixel processing, though. You need to process the entire final image twice. But I've seen worse code in the GD library... Previous Comments: [2006-11-04 18:59:26] [EMAIL PROTECTED] $img = imagecreatetruecolor($width, $height); $bgdalpha = imagecolorallocatealpha($img,0,0,0, 127); imagefill($img, 0,0, $bgdalpha); imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,$srcH); imagesavealpha($img, 1); imagepng($img, 'a.png'); [2006-11-04 18:10:10] seth at pricepages dot org But I *still* can't produce the image that I want. I simply want to enlarge $small. How can I do this? [2006-11-04 17:50:39] [EMAIL PROTECTED] Shouldn't it be default? Backward compatibility... GD is an old library. But things are getting better. No bug bogus. [2006-11-04 17:48:46] seth at pricepages dot org Oh! No, I didn't realize imagesavealpha() existed. Why is saving the alpha a separate function? Shouldn't it be default? [2006-11-04 17:45:05] seth at pricepages dot org I am simply trying to enlarge the original image. I can't find a work-around in PHP, but I can create the image in Adobe Photoshop. This is what I'm attempting to create: http://pricepages.org/temp/partialTrans2.png By the way, this image is the outline of Bermuda. :) 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/39353 -- Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39353 [Bgs]: more imagecopyresized() alpha problems
ID: 39353 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Bogus Bug Type: GD related Operating System: Mac 10.4 PHP Version: 5CVS-2006-11-02 (snap) Assigned To: pajoye New Comment: For example? gdImageCopyResized() in our example (palette - true color, no alpha blending) requires 11+ branches and 3 function calls per input pixel. There is another function call and 4+ branches per output pixel. I'm skipping a good number of branches created by the short-circuiting in each of those 15 if statements. Those create bubbles in your processor pipeline which are going to kill your performance much faster than initializing each pixel 3 times. It's a good thing we are working with small images on fast computers. :) No reply requested. Previous Comments: [2006-11-04 19:32:15] [EMAIL PROTECTED] A last comment is this free support session, you certainly do not know that the default contents of an image create by imagecreatetruecolor is black and not transparent/NULL. [2006-11-04 19:21:46] [EMAIL PROTECTED] That is a workaround. imagecopyresized() isn't working as defined in the manual, so you've changed the destination image to compensate. Now you've reached my patience limit. http://blog.thepimp.net/misc/bug39353_with_alpha.png is exactly what you expect. Now if you do not understand the different between the TRANSPARENT COLOR and the alpha channel of each independent pixel, I cannot help you further. But you keep considering other apps behaviors as what should happen in gd. It is not the case for various reasons (backward compatibility is one of them). But I've seen worse code in the GD library... For example? [2006-11-04 19:16:05] seth at pricepages dot org That is a workaround. imagecopyresized() isn't working as defined in the manual, so you've changed the destination image to compensate. I suppose it's fine if you don't want to fix it, I think I can use this workaround for now. There is a waste of pixel processing, though. You need to process the entire final image twice. But I've seen worse code in the GD library... [2006-11-04 18:59:26] [EMAIL PROTECTED] $img = imagecreatetruecolor($width, $height); $bgdalpha = imagecolorallocatealpha($img,0,0,0, 127); imagefill($img, 0,0, $bgdalpha); imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,$srcH); imagesavealpha($img, 1); imagepng($img, 'a.png'); [2006-11-04 18:10:10] seth at pricepages dot org But I *still* can't produce the image that I want. I simply want to enlarge $small. How can I do this? 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/39353 -- Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39353 [Bgs]: more imagecopyresized() alpha problems
ID: 39353
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
Status: Bogus
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
Well, you can tell me what I'm doing wrong then. I have a
source image with fully transparent pixels. I would like to
copy it over another image, so the final image has fully
transparent pixels.
To do this, I set imagealphablending() to false, and I copy
via imagecopyresized(). But no fully transparent pixels are
copied.
Your statement does not address the second bug that I
mentioned.
Previous Comments:
[2006-11-04 00:17:25] [EMAIL PROTECTED]
But if the alpha blending is set to false, you want to copy
the transparent pixels.
No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.
I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.
[2006-11-03 00:23:48] seth at pricepages dot org
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
tmp = gdImageGetPixel (src, x, y);
if (gdImageGetTransparent (src) == tmp) {
tox += stx[x - srcX];
continue;
}
But if the alpha blending is set to false, you want to copy
the transparent pixels. So commenting out this if statement
removes one bug. There is other similar code in this loop,
so maybe it should all be removed?
Unfortunately, all result pixels still opaque, when the
source image pixels are partially transparent. So this code
does not fix the problem.
Reproduce code:
---
?php
$small = imagecreatefrompng(
'http://pricepages.org/temp/partialTrans.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorresolve($img,255,0,0);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
The image is filled with red, and a partially transparent
black-and-white image is composited on top of it. Because
alpha blending is set to false, there should be no red showing
in the final image. (bug#1, squashed above)
Also, because the greyscale image should have partial
transparency, there should be a gradient between black and
red, but there is none. It is only black or only red. (bug#2)
--
Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39353 [NEW]: more imagecopyresized() alpha problems
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5CVS-2006-11-02 (snap)
PHP Bug Type: GD related
Bug description: more imagecopyresized() alpha problems
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
tmp = gdImageGetPixel (src, x, y);
if (gdImageGetTransparent (src) == tmp) {
tox += stx[x - srcX];
continue;
}
But if the alpha blending is set to false, you want to copy
the transparent pixels. So commenting out this if statement
removes one bug. There is other similar code in this loop,
so maybe it should all be removed?
Unfortunately, all result pixels still opaque, when the
source image pixels are partially transparent. So this code
does not fix the problem.
Reproduce code:
---
?php
$small = imagecreatefrompng(
'http://pricepages.org/temp/partialTrans.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorresolve($img,255,0,0);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW, $srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
The image is filled with red, and a partially transparent
black-and-white image is composited on top of it. Because
alpha blending is set to false, there should be no red showing
in the final image. (bug#1, squashed above)
Also, because the greyscale image should have partial
transparency, there should be a gradient between black and
red, but there is none. It is only black or only red. (bug#2)
--
Edit bug report at http://bugs.php.net/?id=39353edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39353r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39353r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39353r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39353r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39353r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39353r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39353r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39353r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39353r=support
Expected behavior:http://bugs.php.net/fix.php?id=39353r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39353r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39353r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39353r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39353r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39353r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39353r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39353r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39353r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39353r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39353r=mysqlcfg
#39273 [Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
Status: Bogus
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5.1.6
Assigned To: pajoye
New Comment:
I ran your code before I posted my last comment, but I still
don't know what you are implying. The results are exactly as I
expect them to be.
If this bug is bogus, please tell me how I can create an
enlarged version of test.png? It isn't possible without
applying a fix.
Previous Comments:
[2006-10-28 10:49:54] [EMAIL PROTECTED]
I am aware that the image is fully black, except for
variations in alpha. That is why this is a bug related to
the alpha channel and not any other.
You are not aware that your image is *NOT* fully black.
Background color (the transparent color) is not the same than a color
with a ALPHA component. Please run the code I gave you, read the
results (like the values of the channels in these two pixels, or any
other).
[2006-10-27 17:22:07] seth at pricepages dot org
I am aware that the image is fully black, except for
variations in alpha. That is why this is a bug related to
the alpha channel and not any other.
Well, I went in and fixed it myself. The problem was in the
function gdImageGetTrueColorPixel(). It assumed that palette
images always have binary transparency, with a correct value
in im-transparent. Because my source image didn't have a
correct value in im-transparent, it was always marked as
opaque.
This line:
return gdTrueColorAlpha(im-red[p], im-green[p], im-blue
[p], (im-transparent == p) ? gdAlphaTransparent :
gdAlphaOpaque);
Needs to be changed to:
return gdTrueColorAlpha(im-red[p], im-green[p], im-blue
[p], (im-transparent == p) ? gdAlphaTransparent : im-alpha
[p]);
Making this patch also fixes the same bug in
imagecopyresampled(), and who knows what else.
Although, I would recommend using gdTrueColorAlpha() at the
appropriate point(s) in gdImageCopyResized() instead of
gdImageGetTrueColorPixel(). This would eliminate an extra
function call, branch, and color lookup.
[2006-10-27 14:01:12] [EMAIL PROTECTED]
There is nothing wrong in imagecopyresize (or imagecopy).
The problem you have is the misunderstanding of what is the background
color, the alpha channel and alpha blending.
Your original image has many black colors, one is transparent (what you
consider as background), and the other with various transparency
levels.
Try the code below, it will explain you what is your image and how it
works.
?php
$small = imagecreatefrompng('39273.png');
print_r(imagecolortransparent($small));
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
print_r(imagecolorsforindex($small, imagecolorat($small, 0,0)));
// one of the black pixel
print_r(imagecolorsforindex($small, imagecolorat($small, 37,1)));
imagecolortransparent($small, 1);
$img = imagecreatetruecolor($width, $height);
$trans = imagecolorresolve($img,255,255,255);
imagefill($img, 0,0, $trans);
imagecolortransparent($img, $trans);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
imagepng($img, '1.png');
[2006-10-27 07:42:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-10-27 04:17:23] seth at pricepages dot org
Description:
imagecopyresampled() should be copying the alpha channel, but
it doesn't seem to be doing so. This is a palette based source
image being copied to a true color image.
If you use imagecopy() instead, the image copies as expected
(mostly).
Reproduce code:
---
?php
$small = imagecreatefrompng('http://leopold.sage.wisc.edu/test.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
//Make a transparent canvas
$trans = imagecolorresolve($img,255,255,255);
imagecolortransparent($img, $trans);
imagealphablending($img, false);
imagefilledrectangle( $img,
0, 0,
$width, $height,
$trans);
//This shouldn't *need* to be on, but it does
imagealphablending($img, true);
//One of these works, the other doesn't
//imagecopy($img, $small, 0,0, 0,0, $srcW, $srcH);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result
#39273 [Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
Status: Bogus
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5.1.6
Assigned To: pajoye
New Comment:
But that has one of the bugs that I pointed out: boolean
transparency. The original doesn't have that problem.
Previous Comments:
[2006-10-28 14:04:59] [EMAIL PROTECTED]
Use the code I just gave you, it does create the resized version (by
copying):
http://blog.thepimp.net/misc/39273_out.png
[2006-10-28 13:15:45] seth at pricepages dot org
I ran your code before I posted my last comment, but I still
don't know what you are implying. The results are exactly as I
expect them to be.
If this bug is bogus, please tell me how I can create an
enlarged version of test.png? It isn't possible without
applying a fix.
[2006-10-28 10:49:54] [EMAIL PROTECTED]
I am aware that the image is fully black, except for
variations in alpha. That is why this is a bug related to
the alpha channel and not any other.
You are not aware that your image is *NOT* fully black.
Background color (the transparent color) is not the same than a color
with a ALPHA component. Please run the code I gave you, read the
results (like the values of the channels in these two pixels, or any
other).
[2006-10-27 17:22:07] seth at pricepages dot org
I am aware that the image is fully black, except for
variations in alpha. That is why this is a bug related to
the alpha channel and not any other.
Well, I went in and fixed it myself. The problem was in the
function gdImageGetTrueColorPixel(). It assumed that palette
images always have binary transparency, with a correct value
in im-transparent. Because my source image didn't have a
correct value in im-transparent, it was always marked as
opaque.
This line:
return gdTrueColorAlpha(im-red[p], im-green[p], im-blue
[p], (im-transparent == p) ? gdAlphaTransparent :
gdAlphaOpaque);
Needs to be changed to:
return gdTrueColorAlpha(im-red[p], im-green[p], im-blue
[p], (im-transparent == p) ? gdAlphaTransparent : im-alpha
[p]);
Making this patch also fixes the same bug in
imagecopyresampled(), and who knows what else.
Although, I would recommend using gdTrueColorAlpha() at the
appropriate point(s) in gdImageCopyResized() instead of
gdImageGetTrueColorPixel(). This would eliminate an extra
function call, branch, and color lookup.
[2006-10-27 14:01:12] [EMAIL PROTECTED]
There is nothing wrong in imagecopyresize (or imagecopy).
The problem you have is the misunderstanding of what is the background
color, the alpha channel and alpha blending.
Your original image has many black colors, one is transparent (what you
consider as background), and the other with various transparency
levels.
Try the code below, it will explain you what is your image and how it
works.
?php
$small = imagecreatefrompng('39273.png');
print_r(imagecolortransparent($small));
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
print_r(imagecolorsforindex($small, imagecolorat($small, 0,0)));
// one of the black pixel
print_r(imagecolorsforindex($small, imagecolorat($small, 37,1)));
imagecolortransparent($small, 1);
$img = imagecreatetruecolor($width, $height);
$trans = imagecolorresolve($img,255,255,255);
imagefill($img, 0,0, $trans);
imagecolortransparent($img, $trans);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
imagepng($img, '1.png');
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/39273
--
Edit this bug report at http://bugs.php.net/?id=39273edit=1
#39273 [Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Bogus Bug Type: GD related Operating System: Mac 10.4 PHP Version: 5.1.6 Assigned To: pajoye New Comment: translucide (French) = translucent (English) Sorry, that confused me for a bit. Boolean transparency means that the pixel is either fully transparent, or fully opaque. Never partially transparent. The area outside of the line is fine, it should be transparent and it is in your image. This is correct. What is suffering from boolean transparency are the edges of the line. For example: In your example script, one alpha value was 63, and the other was 127. In your output PNG, those values have been changed to 0 and 127. I should mention that if you are using Microsoft's Internet Explorer version 6 or less, a PNG image will display with boolean transparency due to a bug in the browser. So you won't be able to see the difference. Use FireFox. Previous Comments: [2006-10-28 14:19:46] [EMAIL PROTECTED] Pardon? What is a boolean transparency? Please understand these three things: - The transparent color is one *color*, an index for palette based image or 32bits value for truecolor images. It defines which color is used as the *background* color (like white is the background color of a white paper). - The *alpha* channel of a pixel defines how translucide the pixel has to be. It has nothing to do with the transparent color. - Your image has *no* transparent color but many pixels with various *alpha* levels. Load the result images in your favourite paint programs to see what I mean. The area outside the line is translucide, it is due to the alpha channel. [2006-10-28 14:11:56] seth at pricepages dot org But that has one of the bugs that I pointed out: boolean transparency. The original doesn't have that problem. [2006-10-28 14:04:59] [EMAIL PROTECTED] Use the code I just gave you, it does create the resized version (by copying): http://blog.thepimp.net/misc/39273_out.png [2006-10-28 13:15:45] seth at pricepages dot org I ran your code before I posted my last comment, but I still don't know what you are implying. The results are exactly as I expect them to be. If this bug is bogus, please tell me how I can create an enlarged version of test.png? It isn't possible without applying a fix. [2006-10-28 10:49:54] [EMAIL PROTECTED] I am aware that the image is fully black, except for variations in alpha. That is why this is a bug related to the alpha channel and not any other. You are not aware that your image is *NOT* fully black. Background color (the transparent color) is not the same than a color with a ALPHA component. Please run the code I gave you, read the results (like the values of the channels in these two pixels, or any other). 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/39273 -- Edit this bug report at http://bugs.php.net/?id=39273edit=1
#39273 [Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Bogus Bug Type: GD related Operating System: Mac 10.4 PHP Version: 5.1.6 Assigned To: pajoye New Comment: I'm American; if I'm exposed to more than one language my head explodes. ;) Yep, that image is exactly what I'm looking for. Thanks for not just ignoring me after marking the bug bogus, I've had that happen also... Previous Comments: [2006-10-28 15:14:41] [EMAIL PROTECTED] Sorry for my bad wording (images speak better), but we are getting somewhere, finally. We were talking of two different problems. I was talking about a common misunderstanding and you about a more specific problem. Thanks to have insisted and nice catch :) Check this image: http://blog.thepimp.net/misc/39273_out.png Is it what you expect? [2006-10-28 14:43:21] seth at pricepages dot org translucide (French) = translucent (English) Sorry, that confused me for a bit. Boolean transparency means that the pixel is either fully transparent, or fully opaque. Never partially transparent. The area outside of the line is fine, it should be transparent and it is in your image. This is correct. What is suffering from boolean transparency are the edges of the line. For example: In your example script, one alpha value was 63, and the other was 127. In your output PNG, those values have been changed to 0 and 127. I should mention that if you are using Microsoft's Internet Explorer version 6 or less, a PNG image will display with boolean transparency due to a bug in the browser. So you won't be able to see the difference. Use FireFox. [2006-10-28 14:19:46] [EMAIL PROTECTED] Pardon? What is a boolean transparency? Please understand these three things: - The transparent color is one *color*, an index for palette based image or 32bits value for truecolor images. It defines which color is used as the *background* color (like white is the background color of a white paper). - The *alpha* channel of a pixel defines how translucide the pixel has to be. It has nothing to do with the transparent color. - Your image has *no* transparent color but many pixels with various *alpha* levels. Load the result images in your favourite paint programs to see what I mean. The area outside the line is translucide, it is due to the alpha channel. [2006-10-28 14:11:56] seth at pricepages dot org But that has one of the bugs that I pointed out: boolean transparency. The original doesn't have that problem. [2006-10-28 14:04:59] [EMAIL PROTECTED] Use the code I just gave you, it does create the resized version (by copying): http://blog.thepimp.net/misc/39273_out.png 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/39273 -- Edit this bug report at http://bugs.php.net/?id=39273edit=1
#39273 [Bgs-Opn]: imagecopyresized() not compatable with alpha channel
ID: 39273
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
-Status: Bogus
+Status: Open
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5.1.6
Assigned To: pajoye
New Comment:
I am aware that the image is fully black, except for
variations in alpha. That is why this is a bug related to
the alpha channel and not any other.
Well, I went in and fixed it myself. The problem was in the
function gdImageGetTrueColorPixel(). It assumed that palette
images always have binary transparency, with a correct value
in im-transparent. Because my source image didn't have a
correct value in im-transparent, it was always marked as
opaque.
This line:
return gdTrueColorAlpha(im-red[p], im-green[p], im-blue
[p], (im-transparent == p) ? gdAlphaTransparent :
gdAlphaOpaque);
Needs to be changed to:
return gdTrueColorAlpha(im-red[p], im-green[p], im-blue
[p], (im-transparent == p) ? gdAlphaTransparent : im-alpha
[p]);
Making this patch also fixes the same bug in
imagecopyresampled(), and who knows what else.
Although, I would recommend using gdTrueColorAlpha() at the
appropriate point(s) in gdImageCopyResized() instead of
gdImageGetTrueColorPixel(). This would eliminate an extra
function call, branch, and color lookup.
Previous Comments:
[2006-10-27 14:01:12] [EMAIL PROTECTED]
There is nothing wrong in imagecopyresize (or imagecopy).
The problem you have is the misunderstanding of what is the background
color, the alpha channel and alpha blending.
Your original image has many black colors, one is transparent (what you
consider as background), and the other with various transparency
levels.
Try the code below, it will explain you what is your image and how it
works.
?php
$small = imagecreatefrompng('39273.png');
print_r(imagecolortransparent($small));
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
print_r(imagecolorsforindex($small, imagecolorat($small, 0,0)));
// one of the black pixel
print_r(imagecolorsforindex($small, imagecolorat($small, 37,1)));
imagecolortransparent($small, 1);
$img = imagecreatetruecolor($width, $height);
$trans = imagecolorresolve($img,255,255,255);
imagefill($img, 0,0, $trans);
imagecolortransparent($img, $trans);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
imagepng($img, '1.png');
[2006-10-27 07:42:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-10-27 04:17:23] seth at pricepages dot org
Description:
imagecopyresampled() should be copying the alpha channel, but
it doesn't seem to be doing so. This is a palette based source
image being copied to a true color image.
If you use imagecopy() instead, the image copies as expected
(mostly).
Reproduce code:
---
?php
$small = imagecreatefrompng('http://leopold.sage.wisc.edu/test.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
//Make a transparent canvas
$trans = imagecolorresolve($img,255,255,255);
imagecolortransparent($img, $trans);
imagealphablending($img, false);
imagefilledrectangle( $img,
0, 0,
$width, $height,
$trans);
//This shouldn't *need* to be on, but it does
imagealphablending($img, true);
//One of these works, the other doesn't
//imagecopy($img, $small, 0,0, 0,0, $srcW, $srcH);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
An enlarged, pixellated, mostly transparent, image.
Actual result:
--
A black, opaque, image.
--
Edit this bug report at http://bugs.php.net/?id=39273edit=1
#39286 [NEW]: misleading error message with imagecreatefromgd2part()
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5CVS-2006-10-27 (snap)
PHP Bug Type: GD related
Bug description: misleading error message with imagecreatefromgd2part()
Description:
This script results in the error message:
'http://leopold.sage.wisc.edu/world.vis.675.gd2' is not a
valid GD2 file
But it *is* valid. The problem is that the parameter passed
has zero width, but the error message is misleading.
Reproduce code:
---
?php
$img =
imagecreatefromgd2part('http://leopold.sage.wisc.edu/world.vis.675.gd2',
0, 100,0, 100);
/* This works fine:
$img =
imagecreatefromgd2part('http://leopold.sage.wisc.edu/world.vis.675.gd2',
0, 100,100, 100);
*/
header('Content-Type: image/png');
imagepng($img);
?
--
Edit bug report at http://bugs.php.net/?id=39286edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39286r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39286r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39286r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39286r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39286r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39286r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39286r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39286r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39286r=support
Expected behavior:http://bugs.php.net/fix.php?id=39286r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39286r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39286r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39286r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39286r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39286r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39286r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39286r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39286r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39286r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39286r=mysqlcfg
#39273 [NEW]: imagecopyresized() not compatable with alpha channel
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5.1.6
PHP Bug Type: GD related
Bug description: imagecopyresized() not compatable with alpha channel
Description:
imagecopyresampled() should be copying the alpha channel, but
it doesn't seem to be doing so. This is a palette based source
image being copied to a true color image.
If you use imagecopy() instead, the image copies as expected
(mostly).
Reproduce code:
---
?php
$small = imagecreatefrompng('http://leopold.sage.wisc.edu/test.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
//Make a transparent canvas
$trans = imagecolorresolve($img,255,255,255);
imagecolortransparent($img, $trans);
imagealphablending($img, false);
imagefilledrectangle( $img,
0, 0,
$width, $height,
$trans);
//This shouldn't *need* to be on, but it does
imagealphablending($img, true);
//One of these works, the other doesn't
//imagecopy($img, $small, 0,0, 0,0, $srcW, $srcH);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW, $srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
An enlarged, pixellated, mostly transparent, image.
Actual result:
--
A black, opaque, image.
--
Edit bug report at http://bugs.php.net/?id=39273edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39273r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39273r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39273r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39273r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39273r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39273r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39273r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39273r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39273r=support
Expected behavior:http://bugs.php.net/fix.php?id=39273r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39273r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39273r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39273r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39273r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39273r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39273r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39273r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39273r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39273r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39273r=mysqlcfg
#39230 [NEW]: Deep Recusion to Segmentation Fault (Stack Overflow)
From: seth at pricepages dot org Operating system: Mac 10.4 PHP version: 5CVS-2006-10-23 (snap) PHP Bug Type: Reproducible crash Bug description: Deep Recusion to Segmentation Fault (Stack Overflow) Description: Steps to kill PHP dead: - Load test page. - Enter Seth Price as your name - Click the submit button eAccelerator 0.9.5 is installed, but not enabled. I'm running Apache 1.3.33 I'm not sure what would cause this crash, I've run all these bits of code already in similar scripts, but for some reason this kills PHP. Reproduce code: --- Script: http://pricepages.org/temp/test.php.zip Include File: http://pricepages.org/temp/SForm.zip Actual result: -- (gdb) bt [whole lotta stack] ... #60434 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffdfa8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60435 0x02449730 in execute (op_array=0x6d5670) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60436 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60437 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60438 0x02449730 in execute (op_array=0x6d5f70) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60439 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60440 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60441 0x02449730 in execute (op_array=0x2bc970) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60442 0x024192fc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/php/ php5.2-20061030/Zend/zend.c:1097 #60443 0x023a7c48 in php_execute_script (primary_file=0xbfffec70) at /usr/local/php/ php5.2-20061030/main/main.c:1758 #60444 0x024be590 in apache_php_module_main (r=0x183e038, display_source_mode=0) at /usr/local/php/ php5.2-20061030/sapi/apache/sapi_apache.c:53 #60445 0x024bfb58 in send_php (r=0x183e038, display_source_mode=0, filename=0x183fe68 /Library/ WebServer/Documents/test.php) at /usr/local/php/ php5.2-20061030/sapi/apache/mod_php5.c:660 #60446 0x024bfbc0 in send_parsed_php (r=0x183e038) at /usr/ local/php/php5.2-20061030/sapi/apache/mod_php5.c:675 #60447 0xdd04 in ap_invoke_handler () #60448 0x00017dc0 in process_request_internal () #60449 0x00017e40 in ap_process_request () #60450 0x6b4c in child_main () #60451 0x6d04 in make_child () #60452 0x6e68 in startup_children () #60453 0x74d8 in standalone_main () #60454 0x7d60 in main () (gdb) q -- Edit bug report at http://bugs.php.net/?id=39230edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39230r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39230r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39230r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39230r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39230r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39230r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39230r=needscript Try newer version:http://bugs.php.net/fix.php?id=39230r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39230r=support Expected behavior:http://bugs.php.net/fix.php?id=39230r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39230r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39230r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39230r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39230r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39230r=dst IIS Stability:http://bugs.php.net/fix.php?id=39230r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39230r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39230r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39230r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39230r=mysqlcfg
#39230 [Opn]: Deep Recusion to Segmentation Fault (Stack Overflow)
ID: 39230 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Open Bug Type: Reproducible crash Operating System: Mac 10.4 PHP Version: 5CVS-2006-10-23 (snap) New Comment: I figured out that my script was causing the recursion. Inserting $this-freeze(false); on line 70 of SForm/Elm/ Header.php eliminates it. Previous Comments: [2006-10-23 00:28:31] seth at pricepages dot org Description: Steps to kill PHP dead: - Load test page. - Enter Seth Price as your name - Click the submit button eAccelerator 0.9.5 is installed, but not enabled. I'm running Apache 1.3.33 I'm not sure what would cause this crash, I've run all these bits of code already in similar scripts, but for some reason this kills PHP. Reproduce code: --- Script: http://pricepages.org/temp/test.php.zip Include File: http://pricepages.org/temp/SForm.zip Actual result: -- (gdb) bt [whole lotta stack] ... #60434 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffdfa8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60435 0x02449730 in execute (op_array=0x6d5670) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60436 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60437 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60438 0x02449730 in execute (op_array=0x6d5f70) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60439 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60440 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60441 0x02449730 in execute (op_array=0x2bc970) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60442 0x024192fc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/php/ php5.2-20061030/Zend/zend.c:1097 #60443 0x023a7c48 in php_execute_script (primary_file=0xbfffec70) at /usr/local/php/ php5.2-20061030/main/main.c:1758 #60444 0x024be590 in apache_php_module_main (r=0x183e038, display_source_mode=0) at /usr/local/php/ php5.2-20061030/sapi/apache/sapi_apache.c:53 #60445 0x024bfb58 in send_php (r=0x183e038, display_source_mode=0, filename=0x183fe68 /Library/ WebServer/Documents/test.php) at /usr/local/php/ php5.2-20061030/sapi/apache/mod_php5.c:660 #60446 0x024bfbc0 in send_parsed_php (r=0x183e038) at /usr/ local/php/php5.2-20061030/sapi/apache/mod_php5.c:675 #60447 0xdd04 in ap_invoke_handler () #60448 0x00017dc0 in process_request_internal () #60449 0x00017e40 in ap_process_request () #60450 0x6b4c in child_main () #60451 0x6d04 in make_child () #60452 0x6e68 in startup_children () #60453 0x74d8 in standalone_main () #60454 0x7d60 in main () (gdb) q -- Edit this bug report at http://bugs.php.net/?id=39230edit=1
#38452 [Com]: cvs build fails @ --enable-mbstring
ID: 38452 Comment by: seth at pricepages dot org Reported By: openmacnews at gmail dot com Status: Assigned Bug Type: Compile Failure Operating System: OSX 10.4.7 PHP Version: 5CVS-2006-08-14 (CVS) Assigned To: hirokawa New Comment: I just got this error with the latest CVS of PHP 5.2.x. I'm running XCode 2.4. Is this going to be fixed soon? Previous Comments: [2006-08-24 20:48:00] php-bug-38452 at ryandesign dot com I successfully compiled PHP 5.1.4 on Mac OS X 10.4.6 PPC G4 with a certain set of configure options on June 21, 2006, and today I wanted to upgrade to 5.1.5 but got the aforementioned error. Went back and tried to compile the exact same 5.1.4 that worked before, and got same error. So nothing changed in PHP code, but something that changed in the system. According to my installer receipts, since June 21, I have installed Mac OS X 10.4.7, QuickTime 7.1.2, iTunes 6.0.5, Security Update 2006-004 and Xcode 2.4. Interestingly before all this trouble I was able to install PHP 5.1.5 through MacPorts with no errors, and it also enables mbstring. I don't know why it works there and not when I compile manually (even using their exact same configure options). [2006-08-16 15:34:13] openmacnews at gmail dot com I bet openmacnews upgraded XCode between Aug 4th and 14th... yup. I have however discovered something else: it works fine on Intel OS X with XCode 2.4 (MacBook). I'm seeing this problem on a Dual G4, also with XCode 2.4. Looking more like a gcc PPC issue to me. hmm ... all my tests ARE on PPC -- no MacIntels. [2006-08-16 15:22:50] marcus at synchromedia dot co dot uk Well, given that I'm seeing this in 5.1.4, I doubt earlier versions of 5.2 will be any different, and I bet openmacnews upgraded XCode between Aug 4th and 14th... I have however discovered something else: it works fine on Intel OS X with XCode 2.4 (MacBook). I'm seeing this problem on a Dual G4, also with XCode 2.4. Looking more like a gcc PPC issue to me. [2006-08-16 14:25:00] [EMAIL PROTECTED] And if the old code doesn't work for you too, it's likely to be Xcode issue, not PHP. [2006-08-16 14:24:08] [EMAIL PROTECTED] You can try to grab some old CVS code and see if it builds for you. This command would do that for you: cvs -d :pserver:[EMAIL PROTECTED]/repository co -D 2006-month-day 00:00:00 -r PHP_5_2 php-src 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/38452 -- Edit this bug report at http://bugs.php.net/?id=38452edit=1
#38226 [NEW]: Patch for Bug 30863
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5.1.4
PHP Bug Type: GD related
Bug description: Patch for Bug 30863
Description:
This small patch fixes the bug outlined in 30863
(http://bugs.php.net/bug.php?id=30863 ). The problem is a
one pixel shift of the transparency. A one pixel border on
one side remains the default color.
Caution: this fix strikes me as *too* simple. I'm worried
that I'm breaking something that I'm not noticing.
Original code (gd.c line ~1331):
/* If the pixel is transparent, we assign it the
palette index that
* will later be added at the end of the palette as
the transparent
* index. */
if ((oim-transparent = 0) (oim-transparent == *
(inptr - 1)))
{
*outptr++ = nim-colorsTotal;
inptr++;
continue;
}
Fixed code (inptr - 1 changed):
/* If the pixel is transparent, we assign it the
palette index that
* will later be added at the end of the palette as
the transparent
* index. */
if ((oim-transparent = 0) (oim-transparent ==
(*inptr)))
{
*outptr++ = nim-colorsTotal;
inptr++;
continue;
}
In other news:
GD's quantization pngquant
Maybe someday I'll port the code. Interest?
Reproduce code:
---
?php
$img = imagecreatetruecolor(100,100);
//Start with a transparent canvas
$trans = imagecolorresolve($img, 255,255,255);
//Specifying a color as transparent ( below) causes the pixel shift
imagecolortransparent($img, $trans);
imagefilledrectangle($img, 0,0, 100,100, $trans);
//Make a solid grey box
$grey = imagecolorresolve($img, 128,128,128);
imagefilledrectangle($img, 0,50, 100,100, $grey);
//Draw a black line
$black = imagecolorresolve($img, 0,0,0);
imageline($img, 50,0, 50,100, $black);
//Converting to palette ( above) causes a pixel shift
imagetruecolortopalette($img, false, 256);
imagepng($img, 'test.png');
?
--
Edit bug report at http://bugs.php.net/?id=38226edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38226r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38226r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38226r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38226r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38226r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38226r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38226r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38226r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38226r=support
Expected behavior:http://bugs.php.net/fix.php?id=38226r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38226r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38226r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38226r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38226r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38226r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38226r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38226r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38226r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38226r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38226r=mysqlcfg
#38212 [NEW]: Seg Fault on invalid imagecreatefromgd2part() parameters
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5.1.4
PHP Bug Type: Reproducible crash
Bug description: Seg Fault on invalid imagecreatefromgd2part() parameters
Description:
A call to imagecreatefromgd2part() with invalid parameters
(a negative width) causes it to request a negative sized
chunk of memory, and therefore crash.
Reproduce code:
---
?php
//Image file provided on request
$im = imagecreatefromgd2part('test.gd2', 0,0, -25,100);
?
Actual result:
--
(gdb) bt
#0 0x8660 in ___bzero () at /System/Library/Frameworks/
System.framework/PrivateHeaders/ppc/cpu_capabilities.h:187
#1 0x0223a6b8 in _ecalloc (nmemb=19935848, size=4294967247,
__zend_filename=0x2345654 /usr/local/php/php-5.1.4/ext/gd/
libgd/gd.c, __zend_lineno=135, __zend_orig_filename=0x0,
__zend_orig_lineno=19935848) at /usr/local/php/php-5.1.4/
Zend/zend_alloc.c:325
#2 0x0207691c in php_gd_gdImageCreate (sx=-25, sy=125) at /
usr/local/php/php-5.1.4/ext/gd/libgd/gd.c:135
#3 0x0208178c in php_gd_gdImageCreateFromGd2PartCtx
(in=0x11fee18, srcx=0, srcy=425, w=-25, h=125) at /usr/
local/php/php-5.1.4/ext/gd/libgd/gd_gd2.c:447
#4 0x02081dfc in php_gd_gdImageCreateFromGd2Part
(inFile=0x1303268, srcx=0, srcy=425, w=-25, h=125) at /usr/
local/php/php-5.1.4/ext/gd/libgd/gd_gd2.c:405
#5 0x0206c700 in _php_image_create_from (ht=19959208,
return_value=0x11fd368, return_value_ptr=0xf, this_ptr=0x5,
return_value_used=0, image_type=10, tn=0x234530c GD2,
func_p=0x2081dc0 php_gd_gdImageCreateFromGd2Part,
ioctx_func_p=0x20816f0 php_gd_gdImageCreateFromGd2PartCtx)
at /usr/local/php/php-5.1.4/ext/gd/gd.c:1628
#6 0x0206c80c in zif_imagecreatefromgd2part (ht=19935848,
return_value=0xffcf, return_value_ptr=0xf, this_ptr=0x5,
return_value_used=0) at /usr/local/php/php-5.1.4/ext/gd/
gd.c:1750
#7 0x02279f94 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffd878) at /usr/local/php/php-5.1.4/Zend/
zend_vm_execute.h:200
#8 0x02279788 in execute (op_array=0x1148c58) at /usr/
local/php/php-5.1.4/Zend/zend_vm_execute.h:92
--
Edit bug report at http://bugs.php.net/?id=38212edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38212r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38212r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38212r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38212r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38212r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38212r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38212r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38212r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38212r=support
Expected behavior:http://bugs.php.net/fix.php?id=38212r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38212r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38212r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38212r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38212r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38212r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38212r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38212r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38212r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38212r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38212r=mysqlcfg
#38179 [Asn]: Patch to enable copying of partial transparency palette images
ID: 38179 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Assigned Bug Type: GD related Operating System: Mac 10.4 PHP Version: 5.1.4 Assigned To: pajoye New Comment: I've upped an example at: http://pricepages.org/temp/grad.zip Included is the source image, test script, and two output files. The test composites the source image grad.png (a alpha gradient) onto a blank white canvas. test.orig.png is what the output should currently look like. test.patch.png is how it looks after the patch. Previous Comments: [2006-07-23 09:24:19] [EMAIL PROTECTED] Which are you trying to solve? Please post a link to script to reproduce your problem, with the expected image and what you get. [2006-07-21 17:12:47] seth at pricepages dot org Description: I've made a few tweaks to GD to get it to support partial palette transparency better. The (now fixed) problem was that if a partial transparency palette image was copied over any background, the palette image became opaque. http://pricepages.org/temp/trans.diff -- Edit this bug report at http://bugs.php.net/?id=38179edit=1
#38179 [NEW]: Patch to enable copying of partial transparency palette images
From: seth at pricepages dot org Operating system: Mac 10.4 PHP version: 5.1.4 PHP Bug Type: GD related Bug description: Patch to enable copying of partial transparency palette images Description: I've made a few tweaks to GD to get it to support partial palette transparency better. The (now fixed) problem was that if a partial transparency palette image was copied over any background, the palette image became opaque. http://pricepages.org/temp/trans.diff -- Edit bug report at http://bugs.php.net/?id=38179edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38179r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38179r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38179r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38179r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38179r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38179r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38179r=needscript Try newer version:http://bugs.php.net/fix.php?id=38179r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38179r=support Expected behavior:http://bugs.php.net/fix.php?id=38179r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38179r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38179r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38179r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38179r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38179r=dst IIS Stability:http://bugs.php.net/fix.php?id=38179r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38179r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38179r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38179r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38179r=mysqlcfg
