[TYPO3-core] RFC: Bugfix for Image Generation in t3lib_div

[Martin Kutschker]

Ingo Renner schrieb:
> Ingo Renner wrote:
> 
>> The icon get's generated now but has errors. The parts which should be 
>> transparent are black now... (resulting icon attached)
>>
>> It seems though that your patch basically works as the images get 
>> converted to png before they get put together. (found the converted 
>> icons in typo3temp, "readPG_ ... .png")
>>
>> +1 for the patch so far after testing. The issue with the black 
>> transparent areas is a new thing we should fix before comitting the 
>> patch though.
> 
> After some debugging with the lovely xedbug+eclipse combo I found out 
> that somehow that black instead of transparent background gets generated 
> by PHP/GD's own function ImagePng() when called in 
> t3lib_iconWorks::imagecopyresized().
> 
> This function get's called the first time to apply the user icon to the 
> extension icon. The second time that function get's called to apply the 
> little clock icon. When it get's called that second time imagepng() 
> turns that transparent background into a black one.
> 
> There's a longer comment above t3lib_iconWorks::imagecopyresized() where 
> Kasper tries to explain why it uses the way through IM instead of 
> PHP/GD's native imagecopyresized().
> However when forcing TYPO3 to use the native php function all works 
> well. (At least on my configuration: GM, PHP 5.2.4) That's why I'd 
> propose to always use PHP's native imagecopyresized() as in the patch.

In this case the (internal) function can be removed completely.

I am a bit reluctant to remove it like that, when there is such an 
elaborate comment above the code. Anybody knows which PHP version the 
comment is about?

And, more interesting, why creates ImagePng() a black background? Has it 
something to do with imagealphablending() or if the image is created by 
imagecreatetruecolor() or a simple imagecreate()?

Masi