[TYPO3-core] RFC: GIFBUILDER transparency

[Bernhard Kraft]

Hello,


This is a CVS patch request.


BT reference:
http://bugs.typo3.org/view.php?id=2692
http://bugs.typo3.org/view.php?id=2702


Description:
Some people on the newsgroups found a problem with the new GIFBUILDER code. The problem is
that under certain conditions (Read them up in the BT notes) the transparency of GIFBUILDER
labels (images with just text on it) was inverted (Not the background was transparent but
the text)

In the new GIFBUILDER code one of the first operations in the tslib_gifbuilder->make method
is to create the new image and set the background color. There the index of the background
color get's stored in $Bcolor.
Then all actions get performed. It is important to know that during some of those actions
(when for example niceText is set to 1) the image get's written to disk and processed by
image magick.
Now it is the case that some IM/GM versions seem to reorder the color table which is completly
legal for such tools.
When the image get's loaded into php/gd again the color-INDEX of the remembered/stored $Bcolor
variable - the INDEX of the background color - does not correspond to the same color it was before.
(Always remember that $Bcolor contains just an color index and not the RGBA values !)
After all actions are performed the last task is to set the transparent color. When "transparentBackground"
was used to define a transparent area this get's done by simply setting $Bcolor as transparent
color which will obviously not bring the wanted result if the image has been written to disk an
loaded again in the meantime.


Solution:
Just right before the background color shall get set retrieve the color's index fresh from the image
using imageColorExact() and set this index as transparent.



Additional fixes:

*** The bug also fixes the problem that the returnValue of unifyColors was a color-index and "0" is a valid
color-index. But when setting the transparent color from the "transparentColors_Array" variable I just
check for "if ($Tcolor)" which will fail if "0" should be the transparent color.
I modified this to "if ($Tcolor>=0)"


*** I also added some code to the gifbuilder which disables the truecolor flag in t3lib_stdgraphic when:
1. a transparent color is set
AND
2.1 a gif get's created
OR
2.2 reduceColors is set
OR
2.3 a png get's generated and png_truecolor isn't set

The sense of this is to no make any color-reduction when it is avoidable .... Those color reductions most
of the time not look nice and lead to problems with transparency (you define #ffffff to be transparent but
while dithering the image while color-reducing #ffffff became #fdfbfe ... and so this color will not be set
transparent as it has to match the set color exactly.



Files:
gifbuilder_transparency_2006-03-10.diff


PS: Don't forget to remove all files in typo3temp/GB/* typo3temp/menu/* while testing as those don't get removed
by hitting the clear cache buttons and will so not get regenerated - Jörg Wagner who helped to test the solution
had this problem :)


greets,
Bernhard
-- 
----------------------------------------------------------------------
"Freiheit ist immer auch die Freiheit des Andersdenkenden"
Rosa Luxemburg, 1871 - 1919
----------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gifbuilder_transparency_2006-03-10.diff
Type: text/x-patch
Size: 3428 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20060311/cb4db92d/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20060311/cb4db92d/attachment.pgp