TYPO3 Core

I can confirm that on
Debian with PHP 4.4.1,
ImageMagick 5.4.4 and
latest source from CVS.

It works without a problem on the same machine with TYPO3 3.8.0

Now also confirmed on:

Win2003 Standard Edition SP1
Apache2.0.52
PHP Version 4.3.10
GraphicsMagick 1.1.7-Q8

This config also worked flawlessly with T3 3.8.0.

The problem was that when you set #ffffff as backgroundColor for your image this was the very first assigned color and got index "0" ... When setting the transparent color I did a check
if ($Tcolor) {
which of course failed for a color index of "0" (I just read up that imageColorExact which returns the index of a color in an image returns -1 if it fails - I fixed that in the patch attached to this bug note)

I also changed some code which disables truecolor completly if .gif or non-truecolor .png's are going to get generated and transparency get's used.
Real-life examples showed that in most cases transparency didn't work properly there because those images got color reduced at the end and then transparency got lost.
Also when reduceColors get's used and transparency together then truecolor get's disabled.

This is al incorporated in the diff:
gifbuilder_transparency_2006-03-09.diff

Hello Bernhard,
thanks for all your efforts - and especially for your working on this in the middle of the night !!!

Unfortunatelly I can still reproduce the problem after I implemented your patch.
Maybe you did not see it because you could not destinguish between the white font color and the white page background. Please try this TS that should clearly show the problem even on a white page background:

page.100 = IMAGE
 page.100.file = GIFBUILDER
 page.100.file {
    XY = 200,200
    backColor = #333333
    transparentBackground = 1
    10 = TEXT
    10{
      text = Hello
      fontColor = #CCCCCC
      fontSize = 80
      offset = 25,125
      niceText = 1
      fontFile = fileadmin/fonts/ARIALN.TTF
  }
 }
 page.110 = IMAGE
 page.110.file = GIFBUILDER
 page.110.file {
    XY = 200,200
    backColor = #CCCCCC
    transparentBackground = 1
    10 = TEXT
    10{
      text = Hello
      fontColor = #333333
      fontSize = 80
      offset = 25,125
      niceText = 1
      fontFile = fileadmin/fonts/ARIALN.TTF
    }
 }

localconf.php (only GFX entries):

$TYPO3_CONF_VARS['GFX']["im"] = '1';
$TYPO3_CONF_VARS['GFX']['im_combine_filename'] = 'combine';
$TYPO3_CONF_VARS['GFX']["im_path"] = 'C:\\Programme\\GraphicsMagick-1.1.7-Q8\\'; // CHANGE TO YOUR GM PATH!
$TYPO3_CONF_VARS['GFX']["im_path_lzw"] = '';
$TYPO3_CONF_VARS['GFX']['im_version_5'] = 'gm';
$TYPO3_CONF_VARS['GFX']['TTFdpi'] = '96';
$TYPO3_CONF_VARS['GFX']['gdlib_png'] = '0';

Greets,
Jörg.

I set up WAMP (XAMP - wow that's cool - much better like WAMP before) on my Laptop ... altough - this was my last hope before sleeping in front of some VMware or qemu.

I could reproduce the problem with the following setup:
PHP 5.0.1
T3 beta3
apache 2
GM 1.7 Q8 - static

The solution is obvious:
Normally just text get's rendered onto the picture and such stuff but the $this->im variable of the gifbuilder which contains the GD image object always stays the same. But when you now do for example nice-text or any other operation involving GM/IM the file get's saved to the disk and then the result get's loaded again.

In the "make" routine of the Gifbuilder the first thing I do with the newly created image is to set the background color. I remember the color-index in the $Bcolor variable (no - that's not BernhardColor :)
Then all actions get performed. As last step in this method I set the transparent color. Now this problem only occured when "transparentBackground" was set. Because then only the previously remembered color index in the $Bcolor variable got set as transparent color.

And as the file got written down to disk color indexes get juggled around ... simple isn't it.

I think there is no problem when the background color is darker because the colors get ordered by their full 24-bit value. and so the background will stay index 0 when it's a dark color.

So to cut it down this error should have only occured when:
niceText or any other option firing off IM/GM was set.
transparentBackground is set to 1
the background color is not the darkest color in the file ... (try it with 3 colors and tell me if I'm right :)

have phun.

Damn Bernhard,

I see you are going through a lot of trouble to exterminate this very resistant one.
I now installed the patch you provided tonight, but again I have to tell you that the problem persists on my installations.
Is there anything I can do to provide you with debugging information from my system to help you nail it down?

Thanks again for your work!

Cheers,
Jörg Wagner

OFFTOPIC:
Some more information about WAMP installations for developers:
XAMPP is great for development purposes. Just make sure you do not use it on life servers! The installation is clearly aimed at developers and has many security wholes when used without modification on a life server.
Another nice WAMP tool is WOS (Webserver On a Stick - http://www.chsoftware.net/en/useware/wos/wos.htm ). It is not as complex as XAMPP, but it can even be installed on a USB memory key and will run on nearly any Winbox you plug the mem key into. Very nice tool to carry your WAMP installation around in your pocket and use it on any PC you get your hands on. It even exists in a version with preconfigured Typo3 3.8.1!

Bernhard found the solution to the problem. From his postings in typo3.dev:

-----
If you have upgraded an old version of T3 to T3 4.0 then also copy the patched file
tslib/sysext/cms/tslib/class.tslib_gifbuilder.php
to
tslib/class.tslib_gifbuilder.php
normally under linux the later one is a symlink nowadays - and so no patch-code for it
get's included in the diff.
-----
Erase every file out of typo3temp/GB/* and typo3temp/menu/*
-----

The second hint was a direct hit. I thought that clearing the FE cache from the BE would kill all existing gif and png files from the temp folder. But this is not true for the subdirs "GB" and "menu" of typo3temp. They have to be cleared manually (for what reason I do not understand).

Well. I suppose, this one can be marked as RESOLVED now!
Congratulations and many thanks!!!

Just tested Bernhards changes on RC1 (obviously they did not make it into this RC) and they work perfectly.
Thanks again.

I have attached the patched versions of class.tslib_gifbuilder.php and class.t3lib_stdgraphic.php. Please check if the fix works by replacing these files in your 4.0rc1 installation.

Please give feedback asap because we are close before 4.0rc2...

The attached class files are identical to 4.0rc1+BernhardsPatch and I already reported them to work perfectly (they still do).

Sorry, you're right of course. I just forgot to mention that. I uploaded the files for users who might have the same problem but cannot try the fix.

Anyway, Bernhard committed this to CVS this morning, so now it should be resolved. Bernhard, please close.