[TYPO3-core] RFC: GIFBUILDER transparency

[Michael Stucki]

Hi Bernhard,

+1

Didn't understand what you are changing here, but tested that everything
works like in the past (at least in my setup).

According to the bugtracker notes, other users have confirmed that your
patch does what it promises.

Michael

> 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

-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/