#39119 [Csd]: Can't connect to several Online IDS servers
ID: 39119 User updated by: dcalvo at hcuv dot sacyl dot es Reported By: dcalvo at hcuv dot sacyl dot es Status: Closed Bug Type: Informix related Operating System: HP-UX 11i (11.11) PHP Version: 5.1.6 New Comment: Hello again. With version 5.1.6 informix module cann't connect to several IDS database server from the same php page, but with version 4.4.4 it's posible, so there are differencies between version 4 and 5, abd i don't think that the problem was fixed in 5.x version. Previous Comments: [2006-10-28 23:55:25] [EMAIL PROTECTED] So it was fixed in 5.x. Fixed -> closed. [2006-10-28 13:34:26] dcalvo at hcuv dot sacyl dot es I have tried to used the versio 4.4.4 and all work's fine, without any changes on any of my IDS server configuration, so i supose therea are any differencies between version 4 and version 5 of PHP. It is posible to copy the file ext/informix/(ifx.ec from version 4 to the veersion5 one? i supose the answer is no, but i'm not sure. Thank's a lot [2006-10-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-10-10 19:02:28] [EMAIL PROTECTED] I'm afraid there were almost no changes since 4.3.4, so I'd look for some (mis)configuration issues on your machines. [2006-10-10 18:50:11] inform at hcuv dot sacyl dot es Accesing from another Unix server (HP-UX 3) with Apache Web Server 1.3.31 and PHP 4.3.4 it's possible to connect to the IDS1 server without problems. 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/39119 -- Edit this bug report at http://bugs.php.net/?id=39119&edit=1
#39294 [Opn]: "Fatal error: Cannot redeclare class" for classes that use extends
ID: 39294 User updated by: a79315 at hotmail dot com Reported By: a79315 at hotmail dot com Status: Open Bug Type: Class/Object related Operating System: suse 10.1 -PHP Version: 5.1.6 +PHP Version: 5.1.2 New Comment: Should read: If the "extends CTest3" is removed from file test2.inc there is no error. Previous Comments: [2006-10-28 23:39:01] a79315 at hotmail dot com Description: This code works fine on PHP 4 but fails on PHP 5.1.2. I know that I need to try it on the 5.1.6 version but I can't get my suse server to upgrade to it. On PHP 5.1.2 it reports "Fatal error: Cannot redeclare class". If the "extends CTest3" is removed from file test.inc there is no error. Reproduce code: --- File 1: test.php File 2: test2.inc File 3: test3.inc Expected result: No error Actual result: -- Fatal error: Cannot redeclare class ctest2 in test2.inc on line 16 -- Edit this bug report at http://bugs.php.net/?id=39294&edit=1
#39294 [Opn->Bgs]: "Fatal error: Cannot redeclare class" for classes that use extends
ID: 39294
Updated by: [EMAIL PROTECTED]
Reported By: a79315 at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: suse 10.1
PHP Version: 5.1.2
New Comment:
>if (defined("CTEST2")) return;
>define("CTEST2", 1);
Classes are declared at compile time, while 'if() return;' is executed
at runtime, so this is 100% expected behaviour.
Previous Comments:
[2006-10-28 23:46:01] a79315 at hotmail dot com
Should read: If
the "extends CTest3" is removed from file test2.inc there is no error.
[2006-10-28 23:39:01] a79315 at hotmail dot com
Description:
This code works fine on PHP 4 but fails on PHP 5.1.2. I know that I
need to try it on the 5.1.6 version but I can't get my suse server to
upgrade to it. On PHP 5.1.2 it reports "Fatal error: Cannot redeclare
class". If the "extends CTest3" is removed from file test.inc there is
no error.
Reproduce code:
---
File 1: test.php
File 2: test2.inc
File 3: test3.inc
Expected result:
No error
Actual result:
--
Fatal error: Cannot redeclare class ctest2 in test2.inc on line 16
--
Edit this bug report at http://bugs.php.net/?id=39294&edit=1
#39293 [Opn->Fbk]: no GET variables available if one of them is empty
ID: 39293 Updated by: [EMAIL PROTECTED] Reported By: mcalpine at susysearch dot co dot za -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: redhat PHP Version: 4.4.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Can't reproduce. Previous Comments: [2006-10-28 22:23:43] mcalpine at susysearch dot co dot za Description: if a url is sent with one or more of the query variable values empty, eg: index.php?hello=yes&goodbye= , the whole $_GET global is emtpy and the $_SERVER['REQUEST_URI'] is emtpy too. as soon as you send a value for all query variables, the GET and SERVER variables have data. Reproduce code: --- just try var_dump($_GET)... or echo $_SERVER['REQUEST_URI']; Expected result: i would expect to see the url query variables... Actual result: -- described above. -- Edit this bug report at http://bugs.php.net/?id=39293&edit=1
#39119 [Opn->Csd]: Can't connect to several Online IDS servers
ID: 39119
Updated by: [EMAIL PROTECTED]
Reported By: dcalvo at hcuv dot sacyl dot es
-Status: Open
+Status: Closed
Bug Type: Informix related
Operating System: HP-UX 11i (11.11)
PHP Version: 5.1.6
New Comment:
So it was fixed in 5.x.
Fixed -> closed.
Previous Comments:
[2006-10-28 13:34:26] dcalvo at hcuv dot sacyl dot es
I have tried to used the versio 4.4.4 and all work's fine, without any
changes on any of my IDS server configuration, so i supose therea are
any differencies between version 4 and version 5 of PHP.
It is posible to copy the file ext/informix/(ifx.ec from version 4 to
the veersion5 one?
i supose the answer is no, but i'm not sure.
Thank's a lot
[2006-10-18 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-10-10 19:02:28] [EMAIL PROTECTED]
I'm afraid there were almost no changes since 4.3.4, so I'd look for
some (mis)configuration issues on your machines.
[2006-10-10 18:50:11] inform at hcuv dot sacyl dot es
Accesing from another Unix server (HP-UX 3) with Apache Web Server
1.3.31 and PHP 4.3.4 it's possible to connect to the IDS1 server
without problems.
[2006-10-10 18:41:04] dcalvo at hcuv dot sacyl dot es
Description:
Hello.
First of all sorry about my english. I'm Spanish.
I have two HP-UX server with Apache 2.0.58 and PHP compiled as a shared
object with informix CSDK 2.81TC1. Each server has an Informix Online
Dynamic Server 7.31 running. The connectivity between IDS server works
fine from informix dbaccess utility.
When i connect to the informix server located into the unix server
(HP-UX 1) where apache is configured and running i have no problem to
connect and execute any query to access the IDS(1) . When I try to
connect to the other unix server (HP-UX 2) with another IDS 7.31 (IDS
2) running, i can't connect to the remote database host , the error
that the web page shows is SQLCODE=-908.
Doing the same from the other Unix server (HP-UX 2) the situation is
the same, accessing to the local IDS 2 without problem, but can't
connect to the remote database (IDS 1).
I don't know if it's necessary to use the PDO_INFORMIX function to
access Informix Database from PHP 5.1.6, or if this is an environment
variable problem.
Thank's a lot.
Reproduce code:
---
if (!$id_con = ifx_connect("[EMAIL PROTECTED]","username","password"))
{echo "No te conectas.";}
else
{Echo "Conectado con ".$id_con."";
}
Expected result:
Conectado con Resource id #2
Actual result:
--
Warning: ifx_connect() [function.ifx-connect]: E [SQLSTATE=08 004
SQLCODE=-908] in /testpage.php on line 17
No te conectas.
--
Edit this bug report at http://bugs.php.net/?id=39119&edit=1
#39295 [NEW]: openssl_csr_sign and options
From: bassijunior at yahoo dot com dot br Operating system: Windows XP PHP version: 5.1.6 PHP Bug Type: Feature/Change Request Bug description: openssl_csr_sign and options Description: Hi, I'm developing a project that use a openssl functions. I need to write the certificate extension in a x.509 certificate " on the fly". In others words, I will get a data from DB(MYSQL) and then I will write the extension X.509 . Does the openssl_csr_sign can do this? How can I pass more parameters to this function? Is it possible? How can I do this? Thanks!!! -- Edit bug report at http://bugs.php.net/?id=39295&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39295&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39295&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39295&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39295&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39295&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39295&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39295&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39295&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39295&r=support Expected behavior:http://bugs.php.net/fix.php?id=39295&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39295&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39295&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39295&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39295&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39295&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39295&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39295&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39295&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39295&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39295&r=mysqlcfg
#39294 [NEW]: "Fatal error: Cannot redeclare class" for classes that use extends
From: a79315 at hotmail dot com Operating system: suse 10.1 PHP version: 5.1.6 PHP Bug Type: Class/Object related Bug description: "Fatal error: Cannot redeclare class" for classes that use extends Description: This code works fine on PHP 4 but fails on PHP 5.1.2. I know that I need to try it on the 5.1.6 version but I can't get my suse server to upgrade to it. On PHP 5.1.2 it reports "Fatal error: Cannot redeclare class". If the "extends CTest3" is removed from file test.inc there is no error. Reproduce code: --- File 1: test.php File 2: test2.inc File 3: test3.inc Expected result: No error Actual result: -- Fatal error: Cannot redeclare class ctest2 in test2.inc on line 16 -- Edit bug report at http://bugs.php.net/?id=39294&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39294&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39294&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39294&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39294&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39294&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39294&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39294&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39294&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39294&r=support Expected behavior:http://bugs.php.net/fix.php?id=39294&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39294&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39294&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39294&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39294&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39294&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39294&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39294&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39294&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39294&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39294&r=mysqlcfg
#39293 [NEW]: no GET variables available if one of them is empty
From: mcalpine at susysearch dot co dot za Operating system: redhat PHP version: 4.4.4 PHP Bug Type: Unknown/Other Function Bug description: no GET variables available if one of them is empty Description: if a url is sent with one or more of the query variable values empty, eg: index.php?hello=yes&goodbye= , the whole $_GET global is emtpy and the $_SERVER['REQUEST_URI'] is emtpy too. as soon as you send a value for all query variables, the GET and SERVER variables have data. Reproduce code: --- just try var_dump($_GET)... or echo $_SERVER['REQUEST_URI']; Expected result: i would expect to see the url query variables... Actual result: -- described above. -- Edit bug report at http://bugs.php.net/?id=39293&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39293&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39293&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39293&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39293&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39293&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39293&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39293&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39293&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39293&r=support Expected behavior:http://bugs.php.net/fix.php?id=39293&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39293&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39293&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39293&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39293&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39293&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39293&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39293&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39293&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39293&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39293&r=mysqlcfg
#39272 [Fbk->Csd]: Problem on Apache 2.2.3 service Automatic start-up
ID: 39272 User updated by: dj02 dot net at nbl dot fi Reported By: dj02 dot net at nbl dot fi -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: Windows XP 5.1.2600 PHP Version: 5.2.0RC5 New Comment: Works now, PHP 5.2.0RC7-DEV Previous Comments: [2006-10-27 07:41:08] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2006-10-27 00:13:13] dj02 dot net at nbl dot fi Description: When i updated my Apache 2.2.3 server (from PHP 5.1) to PHP 5.2.0 RC6 i started to get problem. Everytime i restart my Windows XP, 5.1.2600 (Finnish, SP 2, ALL Updates Installed) and windows startes to start services on login-screen something happends. On Apache service, it stops starting the service and whole windows locks (no keyactions taked), only Reset button from PC works. So i had to change Apache service startup type: Manual and start it manually after computer restart. In PHP 5.1.6 i didn't have this problem. Windows ErrorEventLog Doesn't show any error. Security software: F-Secure Internet Security 2007 When i start Apache 2.2.3 service manually it hangs few seconds more than in PHP 5.1.6. Reproduce code: --- http://www.finetworks.fi/phpinfo.php Expected result: Apache service stops starting the service and whole windows locks (no keyactions taked), only Reset button from PC works. -- Edit this bug report at http://bugs.php.net/?id=39272&edit=1
#39292 [Opn->Bgs]: for access to a forum
ID: 39292 Updated by: [EMAIL PROTECTED] Reported By: zcrusoe2 at yahoo dot fr -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: OS-dependent PHP Version: 6CVS-2006-10-28 (CVS) New Comment: You need to contact the maintainers of that forum, we're just supplying the computer language that they use. Previous Comments: [2006-10-28 16:46:41] zcrusoe2 at yahoo dot fr Description: When trying to get access to the forum from bof academy or staracademy I have this message that appears: Warning: mysql_connect(): Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug in /home/aceboard/forum/param.php on line 306 -- Edit this bug report at http://bugs.php.net/?id=39292&edit=1
#39292 [NEW]: for access to a forum
From: zcrusoe2 at yahoo dot fr Operating system: OS-dependent PHP version: 6CVS-2006-10-28 (CVS) PHP Bug Type: *General Issues Bug description: for access to a forum Description: When trying to get access to the forum from bof academy or staracademy I have this message that appears: Warning: mysql_connect(): Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug in /home/aceboard/forum/param.php on line 306 -- Edit bug report at http://bugs.php.net/?id=39292&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39292&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39292&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39292&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39292&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39292&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39292&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39292&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39292&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39292&r=support Expected behavior:http://bugs.php.net/fix.php?id=39292&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39292&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39292&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39292&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39292&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39292&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39292&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39292&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39292&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39292&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39292&r=mysqlcfg
#39290 [Bgs]: Unable to load php2apache2.dll in Apache2.2
ID: 39290 User updated by: bentogoa at gmail dot com Reported By: bentogoa at gmail dot com Status: Bogus Bug Type: Apache2 related Operating System: Windosxp PHP Version: 5.1.6 New Comment: Does that mean that i cant use php 5.1.6 and the Earlier versions of Php on Apache 2.2 ? Previous Comments: [2006-10-28 14:23:42] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use php5apache2_2.dll (available since 5.2) [2006-10-28 13:26:16] bentogoa at gmail dot com Description: I am unable to load php2apache2.dll in apache2.2 server on win dows xp only php versions 5.2.0- dev and 6.0 -dev works with Apache 2.2 Server, Apache fails to start with a message "httpd: Syntax error on line 115 of F:/Apache2.2/conf/httpd.conf: Cannot load F:/ php/php5apache2.dll into server: The specified module could not be found." Apache 2.0 can load this module, this problam started when i upgreated to Apache 2.2 -- Edit this bug report at http://bugs.php.net/?id=39290&edit=1
#39289 [Opn->Bgs]: all right in CGI/FastCGI mode, but not right in ISAPI mode.
ID: 39289 Updated by: [EMAIL PROTECTED] Reported By: bin at tbswe dot com -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Windows 2003 PHP Version: 5.1.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-10-28 12:10:24] bin at tbswe dot com Description: I have a Win2003 server with IIS. Today i upgrade to PHP5.1.6 from PHP4.4.4, but a problem came out. It can successful run in CGI mode, but when i changed it to ISAPI mode, it cannot run. Then I tried to call PHPINFO(), It successfully processed, but MYSQL module could not be found in the list.( NO ERROR REPORTING ) In the same PHP.ini, CGI mode could load MYSQL module. And there was "extension=php_mysql.dll" in PHP.INI already. Reproduce code: --- Expected result: MySQL Support enabled Actual result: -- MYSQL could not be found in the list. -- Edit this bug report at http://bugs.php.net/?id=39289&edit=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=39273&edit=1
#39273 [Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273 Updated by: [EMAIL PROTECTED] 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: 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? Previous Comments: [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 [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. 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=39273&edit=1
#39291 [NEW]: ldap_sasl_bind sends wrong authcid
From: lee dot essen at nowonline dot co dot uk Operating system: Solaris 10 PHP version: 5.1.6 PHP Bug Type: LDAP related Bug description: ldap_sasl_bind sends wrong authcid Description: ** Caveat: I am not an LDAP, PHP or SASL expert, so I could be a long way off the mark here ** This is similar to bug 35611 (which is marked as Bogus!) and related to 30189, but I believe the problem is with authcid and not authzid. ldap_sasl_bind sends the binddn as the authcid, this behaviour differs to the standard ldapsearch etc utilities when using "-U" to send a username. This basically means that I cannot get it to bind to my ldap server, looking at the slapd debug it seems to send a username like... username="cn=My Name,ou=People,..." ... when I look at the debug from using an ldapsearch -U it gets a username="shortname" type output. By hacking the code to add another option (authcid) to the php ldap_sasl_bind function and sending that for the authcid instead of binddn everything works perfectly. A simple example is that you don't need to provide a BindDN to ldapsearch if you use -U, this is because the username will be mapped by the authz-regex to a real object. If you don't specify a binddn with PHP you get a "SASL bind in progress" error, and if you just specify a username then it fails with "invalid dn". (I can provide a very simple patch that fixes the problem if it helps) Reproduce code: --- See description above. Expected result: See description above. Actual result: -- See description above. -- Edit bug report at http://bugs.php.net/?id=39291&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39291&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39291&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39291&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39291&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39291&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39291&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39291&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39291&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39291&r=support Expected behavior:http://bugs.php.net/fix.php?id=39291&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39291&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39291&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39291&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39291&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39291&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39291&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39291&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39291&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39291&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39291&r=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: 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=39273&edit=1
#39290 [Opn->Bgs]: Unable to load php2apache2.dll in Apache2.2
ID: 39290 Updated by: [EMAIL PROTECTED] Reported By: bentogoa at gmail dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windosxp PHP Version: 5.1.6 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use php5apache2_2.dll (available since 5.2) Previous Comments: [2006-10-28 13:26:16] bentogoa at gmail dot com Description: I am unable to load php2apache2.dll in apache2.2 server on win dows xp only php versions 5.2.0- dev and 6.0 -dev works with Apache 2.2 Server, Apache fails to start with a message "httpd: Syntax error on line 115 of F:/Apache2.2/conf/httpd.conf: Cannot load F:/ php/php5apache2.dll into server: The specified module could not be found." Apache 2.0 can load this module, this problam started when i upgreated to Apache 2.2 -- Edit this bug report at http://bugs.php.net/?id=39290&edit=1
#39273 [Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273 Updated by: [EMAIL PROTECTED] 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: 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. Previous Comments: [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). [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. 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=39273&edit=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: 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. http://bugs.php.net/39273 -- Edit this bug report at http://bugs.php.net/?id=39273&edit=1
#39290 [NEW]: Unable to load php2apache2.dll in Apache2.2
From: bentogoa at gmail dot com Operating system: Windosxp PHP version: 5.1.6 PHP Bug Type: Apache2 related Bug description: Unable to load php2apache2.dll in Apache2.2 Description: I am unable to load php2apache2.dll in apache2.2 server on win dows xp only php versions 5.2.0- dev and 6.0 -dev works with Apache 2.2 Server, Apache fails to start with a message "httpd: Syntax error on line 115 of F:/Apache2.2/conf/httpd.conf: Cannot load F:/ php/php5apache2.dll into server: The specified module could not be found." Apache 2.0 can load this module, this problam started when i upgreated to Apache 2.2 -- Edit bug report at http://bugs.php.net/?id=39290&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39290&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39290&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39290&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39290&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39290&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39290&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39290&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39290&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39290&r=support Expected behavior:http://bugs.php.net/fix.php?id=39290&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39290&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39290&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39290&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39290&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39290&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39290&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39290&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39290&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39290&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39290&r=mysqlcfg
#39273 [Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273 Updated by: [EMAIL PROTECTED] 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: Use the code I just gave you, it does create the resized version (by copying): http://blog.thepimp.net/misc/39273_out.png Previous Comments: [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. http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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=39273&edit=1
#39119 [NoF->Opn]: Can't connect to several Online IDS servers
ID: 39119
User updated by: dcalvo at hcuv dot sacyl dot es
-Reported By: inform at hcuv dot sacyl dot es
+Reported By: dcalvo at hcuv dot sacyl dot es
-Status: No Feedback
+Status: Open
Bug Type: Informix related
Operating System: HP-UX 11i (11.11)
PHP Version: 5.1.6
New Comment:
I have tried to used the versio 4.4.4 and all work's fine, without any
changes on any of my IDS server configuration, so i supose therea are
any differencies between version 4 and version 5 of PHP.
It is posible to copy the file ext/informix/(ifx.ec from version 4 to
the veersion5 one?
i supose the answer is no, but i'm not sure.
Thank's a lot
Previous Comments:
[2006-10-18 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-10-10 19:02:28] [EMAIL PROTECTED]
I'm afraid there were almost no changes since 4.3.4, so I'd look for
some (mis)configuration issues on your machines.
[2006-10-10 18:50:11] inform at hcuv dot sacyl dot es
Accesing from another Unix server (HP-UX 3) with Apache Web Server
1.3.31 and PHP 4.3.4 it's possible to connect to the IDS1 server
without problems.
[2006-10-10 18:41:04] dcalvo at hcuv dot sacyl dot es
Description:
Hello.
First of all sorry about my english. I'm Spanish.
I have two HP-UX server with Apache 2.0.58 and PHP compiled as a shared
object with informix CSDK 2.81TC1. Each server has an Informix Online
Dynamic Server 7.31 running. The connectivity between IDS server works
fine from informix dbaccess utility.
When i connect to the informix server located into the unix server
(HP-UX 1) where apache is configured and running i have no problem to
connect and execute any query to access the IDS(1) . When I try to
connect to the other unix server (HP-UX 2) with another IDS 7.31 (IDS
2) running, i can't connect to the remote database host , the error
that the web page shows is SQLCODE=-908.
Doing the same from the other Unix server (HP-UX 2) the situation is
the same, accessing to the local IDS 2 without problem, but can't
connect to the remote database (IDS 1).
I don't know if it's necessary to use the PDO_INFORMIX function to
access Informix Database from PHP 5.1.6, or if this is an environment
variable problem.
Thank's a lot.
Reproduce code:
---
if (!$id_con = ifx_connect("[EMAIL PROTECTED]","username","password"))
{echo "No te conectas.";}
else
{Echo "Conectado con ".$id_con."";
}
Expected result:
Conectado con Resource id #2
Actual result:
--
Warning: ifx_connect() [function.ifx-connect]: E [SQLSTATE=08 004
SQLCODE=-908] in /testpage.php on line 17
No te conectas.
--
Edit this bug report at http://bugs.php.net/?id=39119&edit=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 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.
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:
---
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=39273&edit=1
#39289 [NEW]: all right in CGI/FastCGI mode, but not right in ISAPI mode.
From: bin at tbswe dot com Operating system: Windows 2003 PHP version: 5.1.6 PHP Bug Type: Dynamic loading Bug description: all right in CGI/FastCGI mode, but not right in ISAPI mode. Description: I have a Win2003 server with IIS. Today i upgrade to PHP5.1.6 from PHP4.4.4, but a problem came out. It can successful run in CGI mode, but when i changed it to ISAPI mode, it cannot run. Then I tried to call PHPINFO(), It successfully processed, but MYSQL module could not be found in the list.( NO ERROR REPORTING ) In the same PHP.ini, CGI mode could load MYSQL module. And there was "extension=php_mysql.dll" in PHP.INI already. Reproduce code: --- Expected result: MySQL Support enabled Actual result: -- MYSQL could not be found in the list. -- Edit bug report at http://bugs.php.net/?id=39289&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39289&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39289&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39289&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39289&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39289&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39289&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39289&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39289&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39289&r=support Expected behavior:http://bugs.php.net/fix.php?id=39289&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39289&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39289&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39289&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39289&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39289&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39289&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39289&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39289&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39289&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39289&r=mysqlcfg
#39273 [Asn->Bgs]: imagecopyresized() not compatable with alpha channel
ID: 39273
Updated by: [EMAIL PROTECTED]
Reported By: seth at pricepages dot org
-Status: Assigned
+Status: Bogus
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."
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).
Previous Comments:
[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.
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:
---
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=39273&edit=1
#39288 [Opn->Bgs]: Upload failed with file name like {1E0557DF-2797-4E31-9908-81722ABCED19}0.jpg
ID: 39288
Updated by: [EMAIL PROTECTED]
Reported By: chenlailin at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: HTTP related
Operating System: WindowXP SP2
PHP Version: 5.1.6
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2006-10-28 06:15:39] chenlailin at gmail dot com
Description:
upload photo with the name {1E0557DF-2797-4E31-9908-81722ABCED19}0.jpg
It won't work, rename it to
x.jpg,
It works.
Here is the code I used:
$uploadFileWithoutPath =
"photos".basename($_FILES['PhotoUpload']['name']);
$uploadFileWithoutPath = urlencode($uploadFileWithoutPath);
$uploaddir = $PhotoDir;
$uploadfile = $uploaddir . $uploadFileWithoutPath;
$uploadfile = sprintf($uploadfile,time());
$requestValid = true;
$fileSize = $_FILES['PhotoUpload']['size'];
if($fileSize > 100)
{
$requestValid = false;
}
if (move_uploaded_file($_FILES['PhotoUpload']['tmp_name'],
$uploadfile)) {
//do my stuff here...
Reproduce code:
---
http://lab.mytalentexchange.com/
Click a location, and click "add marker" link, try to upload a photo
with the name {1E0557DF-2797-4E31-9908-81722ABCED19}0.jpg
It won't upload the photo, now rename it to
x.jpg,
It works.
--
Edit this bug report at http://bugs.php.net/?id=39288&edit=1
