[PHP-BUG] Req #54619 [NEW]: stripslashes extention

[rc at opelgt dot org]

From: 
Operating system: 
PHP version:  5.3.6
Package:  Arrays related
Bug Type: Feature/Change Request
Bug description:stripslashes extention

Description:

It would be nice (reduces lines in code) when stripslashes could handle
arrays. 

For example stripslashes($_COOKIE);


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

Req #28919 [Com]: foreach does not take list() as argument output

[rc at opelgt dot org]

Edit report at http://bugs.php.net/bug.php?id=28919edit=1

 ID:   28919
 Comment by:   rc at opelgt dot org
 Reported by:  black at scene-si dot org
 Summary:  foreach does not take list() as argument output
 Status:   Open
 Type: Feature/Change Request
 Package:  Feature/Change Request
 Operating System: any
 PHP Version:  Irrelevant

 New Comment:

Why not using this code?



foreach ($table as $key=$val) {

  echo $key.:.$val[0]., .$val[1].\n;

}


Previous Comments:

[2004-06-25 19:48:45] poll...@php.net

This is expected behavior.  list() is a left-hand language construct and
not currently intended to be used this way.



Reclassifying to Feature/Change Request.


[2004-06-25 13:20:05] black at scene-si dot org

Description:

Requesting additional functionality for foreach?

Reproduce code:
---
$table = array();

$table['username'] = array(1,John doe);

$table['black'] = array(2,Jane doe);

$table['yawn'] = array(3,Undefined);



foreach ($table as $key=list($id,$title)) {

  echo $key.:.$id., .$title.\n;

}

foreach ($table as list($id,$title)) {

  echo $id., .$title.\n;

}

Expected result:

username:1, John doe

black:2, Jane doe

yawn:3, Undefined

1, John doe

2, Jane doe

3, Undefined

Actual result:
--
Parse error






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

[PHP-BUG] Req #51797 [NEW]: valid arguments for foreach

[rc at opelgt dot org]

From: 
Operating system: 
PHP version:  5.2.13
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:valid arguments for foreach

Description:

When I give an array to loop through the name of the array and if the array
given 

is with a key, in this case $i, should make no difference.



PHP4 didnt make a warning, PHP5 instead does.

Test script:
---
foreach($array[$i] as $key = $val) results in an warning message.






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

#43729 [NEW]: Fread isnt able to read

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: Mac OS 10.4.11
PHP version:  4.4.7
PHP Bug Type: Filesystem function related
Bug description:  Fread isnt able to read

Description:

Although the pointer is at position 0 and filesize is cached with the 
value of 4 fread reads nothing.

A clearstatcache is necessary for fread to operate correct.

Reproduce code:
---
?php
$str1 = '1234';
$str2 = '56';
$datei = 'test.txt';

$dh = fopen ($datei,w);
fwrite($dh, $str1);
fclose($dh);

$dh = fopen ($datei,r+);
echo 'content: '.fread($dh, filesize($datei)).BR\n;
echo 'pointer after write at: '.ftell($dh).'br';
ftruncate($dh, '0');
echo 'pointer after truncate at: '.ftell($dh).'br';
echo 'filesize after truncate is: '.filesize($datei).'br';
fwrite($dh, $str2);
echo 'pointer after second write at: '.ftell($dh).'br';
rewind($dh);
echo 'pointer after rewind at: '.ftell($dh).'br';
echo 'content: '.fread($dh, filesize($datei)).'br';
clearstatcache();
echo 'content: '.fread($dh, filesize($datei));
fclose($dh);
?

Expected result:

content: 1234
pointer after write at: 4
pointer after truncate at: 4
filesize after truncate is: 4
pointer after second write at: 6
pointer after rewind at: 0
content: 56
content: 56

Actual result:
--
content: 1234
pointer after write at: 4
pointer after truncate at: 4
filesize after truncate is: 4
pointer after second write at: 6
pointer after rewind at: 0
content: 
content: 56

-- 
Edit bug report at http://bugs.php.net/?id=43729edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=43729r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=43729r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=43729r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=43729r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43729r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=43729r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=43729r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43729r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43729r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=43729r=support
Expected behavior:http://bugs.php.net/fix.php?id=43729r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=43729r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=43729r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43729r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=43729r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43729r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43729r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=43729r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=43729r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=43729r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43729r=mysqlcfg

#42874 [NEW]: Feature proposal for print_r (for all PHP versions!)

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: all
PHP version:  5.2.4
PHP Bug Type: Feature/Change Request
Bug description:  Feature proposal for print_r (for all PHP versions!)

Description:

When using print_r for debugging it would be nice to see the name of 
the array. When the default maybe remains without name an additional 
parameter could say if the name of the array shall be displayed too
(or a new function name print_rv with v for verbose?).

now:
Array
(
[0] = K02
[1] = K03
[2] = K01
[3] = K04
[4] = K09
)

proposal:
Array arrayname
(
[0] = K02
[1] = K03
[2] = K01
[3] = K04
[4] = K09
)





-- 
Edit bug report at http://bugs.php.net/?id=42874edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42874r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42874r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42874r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42874r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42874r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42874r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42874r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42874r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42874r=support
Expected behavior:http://bugs.php.net/fix.php?id=42874r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42874r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42874r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42874r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42874r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42874r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42874r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42874r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42874r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42874r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42874r=mysqlcfg

#42876 [NEW]: Feature proposal for print_r (for all PHP versions!)

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: all
PHP version:  5.2.4
PHP Bug Type: Feature/Change Request
Bug description:  Feature proposal for print_r (for all PHP versions!)

Description:

Keeping in mind that print_r is a function this
function should know its parameters. Shouldn't it?

So when i use print_r($class);

why not outputting

Array $class
(
[0] = K02
[1] = K03
[2] = K01
[3] = K04
[4] = K09
)

?



I know what I can do myself, but I think it would be of comfort when 
php itself would mention the name of the shown array.

Do you understand me?

Extending this functions features should not have any disadvantages 
except implementing maybe one line of code.

Kind regards, Rüdiger





-- 
Edit bug report at http://bugs.php.net/?id=42876edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42876r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42876r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42876r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42876r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42876r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42876r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42876r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42876r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42876r=support
Expected behavior:http://bugs.php.net/fix.php?id=42876r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42876r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42876r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42876r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42876r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42876r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42876r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42876r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42876r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42876r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42876r=mysqlcfg

#42877 [NEW]: Feature proposal for print_r (for all PHP versions!)

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: all
PHP version:  5.2.4
PHP Bug Type: Feature/Change Request
Bug description:  Feature proposal for print_r (for all PHP versions!)

Description:

function print_r($a)
 {
  echo Array $a\n {\n  ...
 }

is not that problem.


-- 
Edit bug report at http://bugs.php.net/?id=42877edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42877r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42877r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42877r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42877r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42877r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42877r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42877r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42877r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42877r=support
Expected behavior:http://bugs.php.net/fix.php?id=42877r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42877r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42877r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42877r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42877r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42877r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42877r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42877r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42877r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42877r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42877r=mysqlcfg

#42878 [NEW]: Feature proposal for print_r (for all PHP versions!)

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: all
PHP version:  5.2.4
PHP Bug Type: Feature/Change Request
Bug description:  Feature proposal for print_r (for all PHP versions!)

Description:

My reason for writing was to make PHP a bit more comfortable.
I dont want to spam. I have tried to email you besides this bug 
reporting system at [EMAIL PROTECTED] without success.

You are doing your job for the same reason I do report this: idealism.

I first didnt understood what you meant with variable container 
cause I have studied physics, not informatics.

Now I see the problematic that only the value and not the name is 
given the function print_r.

My native language isnt english but german.

I dont know the internal means of PHP and if a method .name exists.
I only wanted to say it would be nice.

I think that is the critical point very often: first to say Yes I 
understand you, what you want is a good idea, unfortunately its not so 
easy to realize.

?php
function print_rc($variable_name)
 {
  global ${$variable_name};
  echo Array \$$variable_name\n {\n;
  foreach(${$variable_name} as $key = $val) echo   [$key] = 
$val\n;
  echo  }\n;
 }
$arr = array(1,2,3);
print_rc('arr');
?

This is doing what I want. And the problem is instead giving the value 
to the function (print_r) here (print_rc) the name is given.

So my wish is incompatible with the current implementation of PHPs 
print_r.

Its a pity.

Its my part to give this suggestion and its your part to decide 
whether its a nice thing and when yes how that can be implemented.

You can see now that with an optional second parameter in print_r 
(interpreting the given variable as a name) or an additional new php-
function print_rc my wish is possible. With the recent implementation 
of print_r it may not be possible.

I dont want to waste my time describing the current state. I want to 
give a suggestion for the future. Realisation isnt impossible.

Rüdiger


-- 
Edit bug report at http://bugs.php.net/?id=42878edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42878r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42878r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42878r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42878r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42878r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42878r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42878r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42878r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42878r=support
Expected behavior:http://bugs.php.net/fix.php?id=42878r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42878r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42878r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42878r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42878r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42878r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42878r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42878r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42878r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42878r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42878r=mysqlcfg

#42879 [NEW]: Feature proposal for print_r (for all PHP versions!)

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: all
PHP version:  5.2.4
PHP Bug Type: Feature/Change Request
Bug description:  Feature proposal for print_r (for all PHP versions!)

Description:

I can deliver a different function if this is the only problem.

Email me at the given address to avoid misusing this system.

Rüdiger


-- 
Edit bug report at http://bugs.php.net/?id=42879edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42879r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42879r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42879r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42879r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42879r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42879r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42879r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42879r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42879r=support
Expected behavior:http://bugs.php.net/fix.php?id=42879r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42879r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42879r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42879r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42879r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42879r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42879r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42879r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42879r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42879r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42879r=mysqlcfg

#28371 [Opn]: Different behaviour of fopen depending on r+,w+,a+

[rc at opelgt dot org]

 ID:   28371
 User updated by:  rc at opelgt dot org
 Reported By:  rc at opelgt dot org
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: MacOSX 10.3
 PHP Version:  4.3.4
 New Comment:

I think it could be mention in the manual:
In PHP 4.2.3 the read pointer for fopen with 'a' is at 
the end of file. Instead in 4.3.4 the pointer is at '0'!
So rewind for reading in 4.3.4 with 'a+' is no longer 
nessessary.

Rüdiger


Previous Comments:


[2004-05-12 19:12:34] rc at opelgt dot org

Do you really think when such strange differences occur 
and the fopen description says nothing about it, its a 
question for support?

Do you know why this differences occurs?

Output with w+ is:
InhaltBR
alt: BR
neu: 

and with r+:
InhaltBR
alt: 1234567890BR
neu: 

Rüdiger



[2004-05-12 18:52:46] [EMAIL PROTECTED]

The output under both linux and OSX is:

InhaltBR
alt: 1234567890BR
neu: 13579

Your bug report doesn't sound so much like a bug report, but a support
request; this isn't a support forum, so if you don't understand these
results even after careful scrutiny of the fopen() manual page, please
visit http://www.php.net/support.php to find someone who might be able
to help you.



[2004-05-12 17:20:59] rc at opelgt dot org

Description:

Hello,

for my skill its a bit too much to understand whats 
going on here.

Reproduce code:
---
?php
$alt = '1234567890';
$neu = '13579';

$datei = 'test.txt';
$dh = fopen ($datei,w);
fwrite($dh, $alt);
fclose($dh);
// pos1
$dh = fopen ($datei,a+); // just alter the mode to test others
rewind($dh);
echo InhaltBR\nalt: .fread($dh, filesize($datei)).BR\n;
ftruncate($dh, '0');
fwrite($dh, $neu);
rewind($dh);
echo 'neu: '.fread($dh, filesize($datei));
fclose($dh);
?

Expected result:

I wrote the code above and exspected same behaviour for 
r+, w+ and a+.

Before pos1 The content of 'test.txt' is written to 
'1234567890'.
After pos1 the file is opened anothertime with r+,w+ or 
a+.
Rewind sets the pointer to '0'.
So that fread can read the file from the beginning. 
Ftruncate makes the size of the file to '0' and sets the 
pointer to the beginning of the file.
Fwrite writes the new content and the size of the file 
will be as big as nessessary for the content.
Rewind takes the pointer back from end to beginning of 
the file.

Actual result:
--
Echo should tell the new content.
This only works with a+, but with r+ and w+ nothing is 
displayed.

The first echo command tells the 'old' content in a+ and 
r+ mode, but not with w+.

Seems to me there are undocumented differences between 
the modes that makes it difficult to choose and use one 
of them.

Rüdiger





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

#28371 [Opn]: Different behaviour of fopen depending on r+,w+,a+

[rc at opelgt dot org]

 ID:   28371
 User updated by:  rc at opelgt dot org
 Reported By:  rc at opelgt dot org
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: MacOSX 10.3
 PHP Version:  4.3.4
 New Comment:

Yes, my sent script runs identically for all modes under 
Linux and MacOSX.
Its different among the modes.

The mode options in fopen() for my understanding should 
have only effect
for the start: position of pointer, content of file, 
file creation if nessessary or not.
Sure, read or write or both ways of access should remain 
until fclose(). ;-)

'r' and 'w' need clearstatcache() but 'a' doesnt.

That is the unexpected and in the manual not mentioned 
difference.


Previous Comments:


[2004-05-13 14:28:21] rc at opelgt dot org

I think it could be mention in the manual:
In PHP 4.2.3 the read pointer for fopen with 'a' is at 
the end of file. Instead in 4.3.4 the pointer is at '0'!
So rewind for reading in 4.3.4 with 'a+' is no longer 
nessessary.

Rüdiger



[2004-05-12 19:12:34] rc at opelgt dot org

Do you really think when such strange differences occur 
and the fopen description says nothing about it, its a 
question for support?

Do you know why this differences occurs?

Output with w+ is:
InhaltBR
alt: BR
neu: 

and with r+:
InhaltBR
alt: 1234567890BR
neu: 

Rüdiger



[2004-05-12 18:52:46] [EMAIL PROTECTED]

The output under both linux and OSX is:

InhaltBR
alt: 1234567890BR
neu: 13579

Your bug report doesn't sound so much like a bug report, but a support
request; this isn't a support forum, so if you don't understand these
results even after careful scrutiny of the fopen() manual page, please
visit http://www.php.net/support.php to find someone who might be able
to help you.



[2004-05-12 17:20:59] rc at opelgt dot org

Description:

Hello,

for my skill its a bit too much to understand whats 
going on here.

Reproduce code:
---
?php
$alt = '1234567890';
$neu = '13579';

$datei = 'test.txt';
$dh = fopen ($datei,w);
fwrite($dh, $alt);
fclose($dh);
// pos1
$dh = fopen ($datei,a+); // just alter the mode to test others
rewind($dh);
echo InhaltBR\nalt: .fread($dh, filesize($datei)).BR\n;
ftruncate($dh, '0');
fwrite($dh, $neu);
rewind($dh);
echo 'neu: '.fread($dh, filesize($datei));
fclose($dh);
?

Expected result:

I wrote the code above and exspected same behaviour for 
r+, w+ and a+.

Before pos1 The content of 'test.txt' is written to 
'1234567890'.
After pos1 the file is opened anothertime with r+,w+ or 
a+.
Rewind sets the pointer to '0'.
So that fread can read the file from the beginning. 
Ftruncate makes the size of the file to '0' and sets the 
pointer to the beginning of the file.
Fwrite writes the new content and the size of the file 
will be as big as nessessary for the content.
Rewind takes the pointer back from end to beginning of 
the file.

Actual result:
--
Echo should tell the new content.
This only works with a+, but with r+ and w+ nothing is 
displayed.

The first echo command tells the 'old' content in a+ and 
r+ mode, but not with w+.

Seems to me there are undocumented differences between 
the modes that makes it difficult to choose and use one 
of them.

Rüdiger





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

#28371 [NEW]: Different behaviour of fopen depending on r+,w+,a+

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: MacOSX 10.3
PHP version:  4.3.4
PHP Bug Type: Filesystem function related
Bug description:  Different behaviour of fopen depending on r+,w+,a+

Description:

Hello,

for my skill its a bit too much to understand whats 
going on here.

Reproduce code:
---
?php
$alt = '1234567890';
$neu = '13579';

$datei = 'test.txt';
$dh = fopen ($datei,w);
fwrite($dh, $alt);
fclose($dh);
// pos1
$dh = fopen ($datei,a+); // just alter the mode to test others
rewind($dh);
echo InhaltBR\nalt: .fread($dh, filesize($datei)).BR\n;
ftruncate($dh, '0');
fwrite($dh, $neu);
rewind($dh);
echo 'neu: '.fread($dh, filesize($datei));
fclose($dh);
?

Expected result:

I wrote the code above and exspected same behaviour for 
r+, w+ and a+.

Before pos1 The content of 'test.txt' is written to 
'1234567890'.
After pos1 the file is opened anothertime with r+,w+ or 
a+.
Rewind sets the pointer to '0'.
So that fread can read the file from the beginning. 
Ftruncate makes the size of the file to '0' and sets the 
pointer to the beginning of the file.
Fwrite writes the new content and the size of the file 
will be as big as nessessary for the content.
Rewind takes the pointer back from end to beginning of 
the file.

Actual result:
--
Echo should tell the new content.
This only works with a+, but with r+ and w+ nothing is 
displayed.

The first echo command tells the 'old' content in a+ and 
r+ mode, but not with w+.

Seems to me there are undocumented differences between 
the modes that makes it difficult to choose and use one 
of them.

Rüdiger

-- 
Edit bug report at http://bugs.php.net/?id=28371edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28371r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28371r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28371r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28371r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28371r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28371r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28371r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28371r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28371r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28371r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28371r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28371r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28371r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28371r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28371r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28371r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28371r=float

#28371 [Bgs-Opn]: Different behaviour of fopen depending on r+,w+,a+

[rc at opelgt dot org]

 ID:   28371
 User updated by:  rc at opelgt dot org
 Reported By:  rc at opelgt dot org
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: MacOSX 10.3
 PHP Version:  4.3.4
 New Comment:

Do you really think when such strange differences occur 
and the fopen description says nothing about it, its a 
question for support?

Do you know why this differences occurs?

Output with w+ is:
InhaltBR
alt: BR
neu: 

and with r+:
InhaltBR
alt: 1234567890BR
neu: 

Rüdiger


Previous Comments:


[2004-05-12 18:52:46] [EMAIL PROTECTED]

The output under both linux and OSX is:

InhaltBR
alt: 1234567890BR
neu: 13579

Your bug report doesn't sound so much like a bug report, but a support
request; this isn't a support forum, so if you don't understand these
results even after careful scrutiny of the fopen() manual page, please
visit http://www.php.net/support.php to find someone who might be able
to help you.



[2004-05-12 17:20:59] rc at opelgt dot org

Description:

Hello,

for my skill its a bit too much to understand whats 
going on here.

Reproduce code:
---
?php
$alt = '1234567890';
$neu = '13579';

$datei = 'test.txt';
$dh = fopen ($datei,w);
fwrite($dh, $alt);
fclose($dh);
// pos1
$dh = fopen ($datei,a+); // just alter the mode to test others
rewind($dh);
echo InhaltBR\nalt: .fread($dh, filesize($datei)).BR\n;
ftruncate($dh, '0');
fwrite($dh, $neu);
rewind($dh);
echo 'neu: '.fread($dh, filesize($datei));
fclose($dh);
?

Expected result:

I wrote the code above and exspected same behaviour for 
r+, w+ and a+.

Before pos1 The content of 'test.txt' is written to 
'1234567890'.
After pos1 the file is opened anothertime with r+,w+ or 
a+.
Rewind sets the pointer to '0'.
So that fread can read the file from the beginning. 
Ftruncate makes the size of the file to '0' and sets the 
pointer to the beginning of the file.
Fwrite writes the new content and the size of the file 
will be as big as nessessary for the content.
Rewind takes the pointer back from end to beginning of 
the file.

Actual result:
--
Echo should tell the new content.
This only works with a+, but with r+ and w+ nothing is 
displayed.

The first echo command tells the 'old' content in a+ and 
r+ mode, but not with w+.

Seems to me there are undocumented differences between 
the modes that makes it difficult to choose and use one 
of them.

Rüdiger





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

#26254 [Fbk-Opn]: Inaccuracy in imagecopyresized

[rc at opelgt dot org]

 ID:   26254
 User updated by:  rc at opelgt dot org
 Reported By:  rc at opelgt dot org
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: Mac OS X 10.2.8
 PHP Version:  4.3.4
 New Comment:

I used the downloadable version of www.entropy.ch with 
an installer. So I didnt change something of that. Here 
is what phpinfo tells about the configuration command:

'./configure' '--prefix=/usr/local/php' '--with-config-
file-path=/usr/local/php/lib' '--with-apxs' '--with-
iconv=/usr/local/php' '--with-openssl=/usr' '--with-
zlib=/usr' '--with-mysql' '--with-pgsql=/Users/marc/
cvs/entropy/php-module/build/postgresql-build' '--
enable-cgi' '--with-gd' '--with-png-dir=/usr/local/php' 
'--with-freetype-dir=/usr/local/php' '--with-t1lib=/
usr/local/php' '--with-jpeg-dir=/usr/local/php' '--
with-tiff-dir=/usr/local/php' '--with-curl=/usr/local/
php' '--with-mcal=/usr/local/php' '--with-mcrypt=/usr/
local/php' '--with-mhash=/usr/local/php' '--with-
pdflib=/usr/local/php' '--with-imap=../imap-2002d' '--
with-imap-ssl=/usr' '--with-expat-dir=/usr/local/php' 
'--with-gettext=/usr/local/php' '--with-dom=/usr/local/
php' '--with-dom-xslt=/usr/local/php' '--with-dom-
exslt=/usr/local/php' '--with-xslt-sablot=/usr/local/
php' '--with-mssql=/usr/local/php' '--enable-xslt' '--
with-ldap' '--with-xmlrpc' '--with-xml' '--with-iodbc' 
'--enable-sockets' '--enable-dbx' '--enable-dbase' '--
enable-trans-sid' '--enable-exif' '--enable-wddx' '--
enable-ftp' '--enable-mbstring'


Previous Comments:


[2003-11-17 22:48:20] [EMAIL PROTECTED]

What was the configure line you used? 




[2003-11-17 08:22:47] rc at opelgt dot org

When the destination image is created with 
imagecreatetruecolor the behaviour seems to be ok.
So the bug is obviously for a palette based image.



[2003-11-17 07:48:31] rc at opelgt dot org

The bug is still existing in 4.3.4 R1.
So in PHP5 it is solved?



[2003-11-16 13:13:10] [EMAIL PROTECTED]

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php





[2003-11-16 11:43:37] rc at opelgt dot org

The upper left corner was placed correctly but the 
height was one pixel too small.
I have updated to 4.3.4 R1 and it seems to be ok now.



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

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

#26254 [Csd-Opn]: Inaccuracy in imagecopyresized

[rc at opelgt dot org]

 ID:   26254
 User updated by:  rc at opelgt dot org
 Reported By:  rc at opelgt dot org
-Status:   Closed
+Status:   Open
 Bug Type: GD related
 Operating System: Mac OS X 10.2.8
 PHP Version:  4.3.3/4.3.4 R1
 New Comment:

The bug is still existing in 4.3.4 R1.
So in PHP5 it is solved?


Previous Comments:


[2003-11-16 13:13:10] [EMAIL PROTECTED]

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php





[2003-11-16 11:43:37] rc at opelgt dot org

The upper left corner was placed correctly but the 
height was one pixel too small.
I have updated to 4.3.4 R1 and it seems to be ok now.



[2003-11-14 14:10:22] rc at opelgt dot org

Description:

My value for the destination height is correct. The 
result on screen is one pixel too small.

Kind regards, Rüdiger






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

#26254 [Opn]: Inaccuracy in imagecopyresized

[rc at opelgt dot org]

 ID:   26254
 User updated by:  rc at opelgt dot org
 Reported By:  rc at opelgt dot org
 Status:   Open
 Bug Type: GD related
 Operating System: Mac OS X 10.2.8
 PHP Version:  4.3.3/4.3.4 R1
 New Comment:

When the destination image is created with 
imagecreatetruecolor the behaviour seems to be ok.
So the bug is obviously for a palette based image.


Previous Comments:


[2003-11-17 07:48:31] rc at opelgt dot org

The bug is still existing in 4.3.4 R1.
So in PHP5 it is solved?



[2003-11-16 13:13:10] [EMAIL PROTECTED]

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php





[2003-11-16 11:43:37] rc at opelgt dot org

The upper left corner was placed correctly but the 
height was one pixel too small.
I have updated to 4.3.4 R1 and it seems to be ok now.



[2003-11-14 14:10:22] rc at opelgt dot org

Description:

My value for the destination height is correct. The 
result on screen is one pixel too small.

Kind regards, Rüdiger






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

#26254 [Opn]: Inaccuracy in imagecopyresized

[rc at opelgt dot org]

 ID:   26254
 User updated by:  rc at opelgt dot org
 Reported By:  rc at opelgt dot org
 Status:   Open
 Bug Type: GD related
 Operating System: Mac OS X 10.2.8
-PHP Version:  4.3.3
+PHP Version:  4.3.3/4.3.4 R1
 New Comment:

The upper left corner was placed correctly but the 
height was one pixel too small.
I have updated to 4.3.4 R1 and it seems to be ok now.


Previous Comments:


[2003-11-14 14:10:22] rc at opelgt dot org

Description:

My value for the destination height is correct. The 
result on screen is one pixel too small.

Kind regards, Rüdiger






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

#26254 [NEW]: Inaccuracy in imagecopyresized

[rc at opelgt dot org]

From: rc at opelgt dot org
Operating system: Mac OS X 10.2.8
PHP version:  4.3.3
PHP Bug Type: GD related
Bug description:  Inaccuracy in imagecopyresized

Description:

My value for the destination height is correct. The 
result on screen is one pixel too small.

Kind regards, Rüdiger


-- 
Edit bug report at http://bugs.php.net/?id=26254edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26254r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26254r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26254r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26254r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26254r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26254r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26254r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26254r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26254r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26254r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26254r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26254r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26254r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26254r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26254r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26254r=float

#21612 [NEW]: Enhancing include()

[rc]

From: [EMAIL PROTECTED]
Operating system: all
PHP version:  4.3.0
PHP Bug Type: Feature/Change Request
Bug description:  Enhancing include()

At the moment include() is only supporting files as arguments.
Why not using array elements too?

My excample:
I have have a php-page that reads in text files and shows their content:
http://christophorusschule-hamburg.de depending on the two parameters
menu(m) and submenue(u).

For http://christophorusschule-hamburg.de?m=6u=3 I want to show what
setting of color and resolution is selected at the moment. So I need to
have php-code included. The source is in a txt-file and after exploding in
an array element. I want to use an if statement: if array element begins
with ?php than the content shall be included, otherwise the content shall
be echoed.

With kind regards, Rüdiger
-- 
Edit bug report at http://bugs.php.net/?id=21612edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21612r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21612r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21612r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21612r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21612r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21612r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21612r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21612r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21612r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21612r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21612r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21612r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21612r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21612r=gnused

#21612 [Opn]: Enhancing include()

[rc]

 ID:   21612
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.3.0
 New Comment:

At the moment include() is only supporting files as arguments.
Why not using array elements too?

My excample:
I have have a php-page that reads in text files and shows their
content:
http://christophorusschule-hamburg.de depending on the two
parameters menu(m) and submenue(u).

For http://christophorusschule-hamburg.de/basis.php?m=6u=3 I want to
show what setting of color and resolution is selected at the moment. So
I need to have php-code included. The source for this and all the other
pages resides in a txt-file and after exploding in an array element. I
want to use an if statement: if array element begins with ?php than
the content shall be included, otherwise the content shall be echoed.

With kind regards, Rüdiger


Previous Comments:


[2003-01-13 04:58:39] [EMAIL PROTECTED]

At the moment include() is only supporting files as arguments.
Why not using array elements too?

My excample:
I have have a php-page that reads in text files and shows their
content: http://christophorusschule-hamburg.de depending on the two
parameters menu(m) and submenue(u).

For http://christophorusschule-hamburg.de?m=6u=3 I want to show what
setting of color and resolution is selected at the moment. So I need to
have php-code included. The source is in a txt-file and after exploding
in an array element. I want to use an if statement: if array element
begins with ?php than the content shall be included, otherwise the
content shall be echoed.

With kind regards, Rüdiger




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

#20880 [Opn]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic

[rc]

 ID:   20880
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Mac OSX 10.2.2
 PHP Version:  4.2.3
 New Comment:

The application is at http://rc.opelgt.org/rechnereien/tacho.html
The two gifs are at http://rc.opelgt.org/rechnereien/diagramm.gif and
http://rc.opelgt.org/rechnereien/verdeck.gif
The two pngs are at http://rc.opelgt.org/rechnereien/diagramm.png and
http://rc.opelgt.org/rechnereien/verdeck.png
The php code is
?php
header (Content-type: image/png);
$im = ImageCreateFromPNG (diagramm.png)
   or die (Kann keinen neuen GD-Bild-Stream erzeugen);
$im2 = ImageCreateFromPNG (verdeck.png);
ImageCopy ($im, $im2, 0, 187, 0, 0, 17, 17);
ImagePNG ($im);
?
A test html page for easy viewing with dark background
HTMLHEAD/HEAD
BODY BGCOLOR=#99
PIMG SRC=diagrammping.php WIDTH=174 HEIGHT=230 ALIGN=bottom/P
/BODY/HTML

The two pngs are created with Adobe PhotoShop 6.
I tried to solve the problem with different colors in the two pings
marked as transparent (before both #00FF00) but without success.

Rüdiger


Previous Comments:


[2002-12-07 20:46:08] [EMAIL PROTECTED]

Hello,

A quick test helpfull to find out what happens with your image, can you
provide a url (html page) with the 2 original images you use to create
the final gif image you provided as a link, and a short script to
reproduce it.

About a compiler on a macos platform, you may take a look at:
http://www.phpmac.com/

pierre



[2002-12-07 19:45:20] [EMAIL PROTECTED]

Hello Pierre,

as mentioned I have a Mac and using a C-Compiler is beyond my
possibilities.

I will wait for 4.3 as a Mac-Version.
Rüdiger

P.s.: Or do you have a source for a free C-Compiler for Mac OSX?



[2002-12-07 19:30:53] [EMAIL PROTECTED]

Try what?

These 2 links pointed you to the latest development version of php. The
1st link is the linux sources, the 2nd in the windows binary version
(which you can use on a windows box as a full replacement of your
current installation for tests purpose).

In the case you will test with one these version, please use the
bundled gd library (compile with --with-gd to get it).

Then can you try to export it as a png image and post an url here ?

pierre


You have sent me twice the same link.
When I have no C-Compiler (or what kind of source is this?)
what shall I do with it?



[2002-12-07 19:11:32] [EMAIL PROTECTED]

Try what?
You have sent me twice the same link.
When I have no C-Compiler (or what kind of source is this?)
what shall I do with it?

Rüdiger



[2002-12-07 17:34:26] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Download the latest PHP snapshot from the URL in this message and try
it.



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

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

#20880 [Csd]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic

[rc]

 ID:   20880
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: GD related
 Operating System: Mac OSX 10.2.2
 PHP Version:  4.2.3
 New Comment:

Thank you too ;-)

Rüdiger


Previous Comments:


[2002-12-08 11:56:02] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

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

The current cvs works well with the provided images. Try your script
with the cvs version.

Thank's the report,

pierre



[2002-12-08 02:37:29] [EMAIL PROTECTED]

The application is at http://rc.opelgt.org/rechnereien/tacho.html
The two gifs are at http://rc.opelgt.org/rechnereien/diagramm.gif and
http://rc.opelgt.org/rechnereien/verdeck.gif
The two pngs are at http://rc.opelgt.org/rechnereien/diagramm.png and
http://rc.opelgt.org/rechnereien/verdeck.png
The php code is
?php
header (Content-type: image/png);
$im = ImageCreateFromPNG (diagramm.png)
   or die (Kann keinen neuen GD-Bild-Stream erzeugen);
$im2 = ImageCreateFromPNG (verdeck.png);
ImageCopy ($im, $im2, 0, 187, 0, 0, 17, 17);
ImagePNG ($im);
?
A test html page for easy viewing with dark background
HTMLHEAD/HEAD
BODY BGCOLOR=#99
PIMG SRC=diagrammping.php WIDTH=174 HEIGHT=230 ALIGN=bottom/P
/BODY/HTML

The two pngs are created with Adobe PhotoShop 6.
I tried to solve the problem with different colors in the two pings
marked as transparent (before both #00FF00) but without success.

Rüdiger



[2002-12-07 20:46:08] [EMAIL PROTECTED]

Hello,

A quick test helpfull to find out what happens with your image, can you
provide a url (html page) with the 2 original images you use to create
the final gif image you provided as a link, and a short script to
reproduce it.

About a compiler on a macos platform, you may take a look at:
http://www.phpmac.com/

pierre



[2002-12-07 19:45:20] [EMAIL PROTECTED]

Hello Pierre,

as mentioned I have a Mac and using a C-Compiler is beyond my
possibilities.

I will wait for 4.3 as a Mac-Version.
Rüdiger

P.s.: Or do you have a source for a free C-Compiler for Mac OSX?



[2002-12-07 19:30:53] [EMAIL PROTECTED]

Try what?

These 2 links pointed you to the latest development version of php. The
1st link is the linux sources, the 2nd in the windows binary version
(which you can use on a windows box as a full replacement of your
current installation for tests purpose).

In the case you will test with one these version, please use the
bundled gd library (compile with --with-gd to get it).

Then can you try to export it as a png image and post an url here ?

pierre


You have sent me twice the same link.
When I have no C-Compiler (or what kind of source is this?)
what shall I do with it?



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

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

#20880 [Opn]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic

[rc]

 ID:   20880
 User updated by:  [EMAIL PROTECTED]
-Summary:  In ImageCopy transparency of the top grafic dominates
   colors othe bottom grafic
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Mac OSX 10.2.2
 PHP Version:  4.2.3
 New Comment:

I have two png-files, both with transparency.
With ImageCopy the transparency area of the second graphic will
dominate the white area of the first graphic at the bottom.
Example at http://rc.opelgt.org/rechnereien/bug.gif
in the left bottom (origin) of the diagramm:
   Ok: at the left  GD 1.6 with GIFs,
  bad: at the right GD 2.0 with PNGs.

My suggestion:
a switch to set the behavior
1. transparency of the second leaves the bottom grafic unmodified. Good
for my application.
2. transparency of the second grafic dominates the first grafic. Good
for perforating the first grafic

With kind regards,
Rüdiger


Previous Comments:


[2002-12-07 12:03:51] [EMAIL PROTECTED]

I have two png-files, both with transparency.
With ImageCopy the transparency area of the second graphic will
dominate the white area of the first graphic at the bottom.
Example at http://rc.opelgt.org/rechnereien/bug.gif
in the left bottom (origin) of the diagramm:
 Ok: at the left  GD 1.6 with GIFs,
bad: at the right GD 2.0 with PNGs.

With kind regards,
Rüdiger




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

#20880 [Fbk-Opn]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic

[rc]

 ID:   20880
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: Mac OSX 10.2.2
 PHP Version:  4.2.3
 New Comment:

Thanks for fast response. What did you mail me?
Source code?
I do not know what to do with it.

Sorry, Rüdiger


Previous Comments:


[2002-12-07 15:09:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Please use the bundled gd included with the STABLE snapshot.



[2002-12-07 12:36:23] [EMAIL PROTECTED]

I have two png-files, both with transparency.
With ImageCopy the transparency area of the second graphic will
dominate the white area of the first graphic at the bottom.
Example at http://rc.opelgt.org/rechnereien/bug.gif
in the left bottom (origin) of the diagramm:
   Ok: at the left  GD 1.6 with GIFs,
  bad: at the right GD 2.0 with PNGs.

My suggestion:
a switch to set the behavior
1. transparency of the second leaves the bottom grafic unmodified. Good
for my application.
2. transparency of the second grafic dominates the first grafic. Good
for perforating the first grafic

With kind regards,
Rüdiger



[2002-12-07 12:03:51] [EMAIL PROTECTED]

I have two png-files, both with transparency.
With ImageCopy the transparency area of the second graphic will
dominate the white area of the first graphic at the bottom.
Example at http://rc.opelgt.org/rechnereien/bug.gif
in the left bottom (origin) of the diagramm:
 Ok: at the left  GD 1.6 with GIFs,
bad: at the right GD 2.0 with PNGs.

With kind regards,
Rüdiger




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

#20880 [Fbk-Opn]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic

[rc]

 ID:   20880
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: Mac OSX 10.2.2
 PHP Version:  4.2.3
 New Comment:

Try what?
You have sent me twice the same link.
When I have no C-Compiler (or what kind of source is this?)
what shall I do with it?

Rüdiger


Previous Comments:


[2002-12-07 17:34:26] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Download the latest PHP snapshot from the URL in this message and try
it.



[2002-12-07 17:22:44] [EMAIL PROTECTED]

Thanks for fast response. What did you mail me?
Source code?
I do not know what to do with it.

Sorry, Rüdiger



[2002-12-07 15:09:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Please use the bundled gd included with the STABLE snapshot.



[2002-12-07 12:36:23] [EMAIL PROTECTED]

I have two png-files, both with transparency.
With ImageCopy the transparency area of the second graphic will
dominate the white area of the first graphic at the bottom.
Example at http://rc.opelgt.org/rechnereien/bug.gif
in the left bottom (origin) of the diagramm:
   Ok: at the left  GD 1.6 with GIFs,
  bad: at the right GD 2.0 with PNGs.

My suggestion:
a switch to set the behavior
1. transparency of the second leaves the bottom grafic unmodified. Good
for my application.
2. transparency of the second grafic dominates the first grafic. Good
for perforating the first grafic

With kind regards,
Rüdiger



[2002-12-07 12:03:51] [EMAIL PROTECTED]

I have two png-files, both with transparency.
With ImageCopy the transparency area of the second graphic will
dominate the white area of the first graphic at the bottom.
Example at http://rc.opelgt.org/rechnereien/bug.gif
in the left bottom (origin) of the diagramm:
 Ok: at the left  GD 1.6 with GIFs,
bad: at the right GD 2.0 with PNGs.

With kind regards,
Rüdiger




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

#20880 [Opn]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic

[rc]

 ID:   20880
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Mac OSX 10.2.2
 PHP Version:  4.2.3
 New Comment:

Hello Pierre,

as mentioned I have a Mac and using a C-Compiler is beyond my
possibilities.

I will wait for 4.3 as a Mac-Version.
Rüdiger

P.s.: Or do you have a source for a free C-Compiler for Mac OSX?


Previous Comments:


[2002-12-07 19:30:53] [EMAIL PROTECTED]

Try what?

These 2 links pointed you to the latest development version of php. The
1st link is the linux sources, the 2nd in the windows binary version
(which you can use on a windows box as a full replacement of your
current installation for tests purpose).

In the case you will test with one these version, please use the
bundled gd library (compile with --with-gd to get it).

Then can you try to export it as a png image and post an url here ?

pierre


You have sent me twice the same link.
When I have no C-Compiler (or what kind of source is this?)
what shall I do with it?



[2002-12-07 19:11:32] [EMAIL PROTECTED]

Try what?
You have sent me twice the same link.
When I have no C-Compiler (or what kind of source is this?)
what shall I do with it?

Rüdiger



[2002-12-07 17:34:26] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Download the latest PHP snapshot from the URL in this message and try
it.



[2002-12-07 17:22:44] [EMAIL PROTECTED]

Thanks for fast response. What did you mail me?
Source code?
I do not know what to do with it.

Sorry, Rüdiger



[2002-12-07 15:09:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Please use the bundled gd included with the STABLE snapshot.



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

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