Next message: Arnar Mar Hrafnkelsson: "Imager-0.38pre9 Released."
On Wed, 2 May 2001, Mike Depot wrote:
> Below is my attempt at solving this problem. I turned on antialiasing for
> the font so a smaller text size would be readable. It works great for PNG,
> but there's still a problem with the GIF version. The code below creates
> three images. The first image, date1.gif, looks great, but it's rendered on
> a white background instead of transparent. The second image, date2.png,
> seems to have dealt with the transparancy perfectly.
> The problem occurs in date3.gif. When write() did it's processing for
> transparency, it seems to have chosen blending colors assuming the
> background was black. This means black text on an assumed black background
> didn't get any antialiasing. Around the orange text, you can still see some
> antialiased pixels that are half way between orange and black.
You're right. The problem isn't that the code chose bad blending colours,
it's more that it doesn't try to do blending at all, and hence just uses
the raw colours in the RGB channels, giving the result you're seeing.
This is probably a bug :)
There is a workaround though, before writing to the image set it's
background to your blending colour, _but_ set the alpha for that colour to
You could put:
+ my $blend = NC(255,255,255,0);
If that make sense.
> How would you make the antialiasing processing that write() uses for GIF
> images assume a paticular color background for transparent pixels? To get
> the desired result in this case, I would have wanted it to assume white
> instead of a black.
I admit I simply didn't think of it when writing the code.
Since the current code separates transparency from colour handling it's
going to hurt my head to fix it <sigh>.