TYPO3 Core

The problem which I think may be solved is described in TSRef:
"transparentColor
[...]
Option:
transparentColor.closest = 1

This will allow for the closest color to be matched instead. You may need this if you image is not garanteed "clean".

NOTE: You may experience that this doesn't work if you use reduceColors-option or render text with niceText-option."

Yes, the experience is that this is very visible: The transparent images will as from my experience definitely have a distored pixel-cloud around, since niceText will add surrounding pixels in different colors for realizing anti-aliasing. closest seems not to change anything.

The following patch adds some more "magic" to the parameter transparentColor.closest (which I think is not described adequately in TSRef anyway, since from what I understand will have no effect if not adding additional colors separated by | to transparentColor).

So, imagine if
transparentColor = #FFFFFF
transparentColor.closest = 1
was set and some TEXT object generated with niceText = 1

Old behaviour:
No change at all (please correct me if I'm wrong)... for having effect one would have had to apply f.e.
transparentColor = #FFFFFF | #FEFEFE
and then would have replaced both colors to transparency. Not a very helpful option when working with niceText, since one will not know which colors have to be made transparent.

Behaviour after patching:
The closest value is not any longer just a boolean, but gives a percentage value for the Image/GraphicsMagick parameter -fuzz and thus might have as well higher int values for different results. (see http://www.imagemagick.org/script/command-line-options.php#fuzz ).

As from my experience -fuzz has a quite visible (and appreciated) effect for niceText and transparentColor even with low percentage values (given by transparentColor.closest), but of course may depend on the type of image.

It would allow easy configuration for GIFBUILDER images with niceText and transparents background but without pixel-clouds - and provides a solution for the TSRef mentioned problem.

(issue imported from #M6604)