Anti-aliasing bug (with text/labels)
Steve.Lime at DNR.STATE.MN.US
Fri Apr 21 23:40:16 EDT 2006
Curious bug... The value sent to the gdImageStringFT function is a color index not the color itself.
For 8-bit images the first color allocated is always 0 and is the background color for the image. Typically you don't label with that color since labels would fade into the background, but you may outline labels with it.
For 24-bit images I don't know how GD arrives at the pen value. If there is a RGB value that is returned as 0 from the color allocation functions then there would be a problem.
I'm not sure how to address the bug since it's clearly a GD issue. They should work from an anti-aliasing flag rather than using the color index. The work around in either the 8-bit or 24-bit case would be avoiding the 0 color index if you really need to turn off anti-aliasing (e.g. avoid the IMAGECOLOR and black).
I'm open to suggestions...
>>> Jani Averbach <javerbach at EXTENDTHEREACH.COM> 04/21/06 5:01 PM >>>
I have found a bug in Mapserver with anti-aliasing code when
black text (#000000) is always anti-aliased.
The problem is that there is following kind of code in the
mapgd.c::msDrawTextGD, around line 3090
And the GD Manual says:
The string is rendered in the color indicated by the gf color index.
Use the negative of the desired color index to disable anti-aliasing.
However, for pure black the pen is zero and there isn't such a thing as
So black text is always anti-aliased regardless of if you are using
ANTIALIAS FALSE or not.
I have included a small map-file to demonstrate that bug.
SIZE 100 100
EXTENT 0 0 10 10
COLOR 0 0 0
#COLOR 1 1 1
SRC in Action:
Join SRC at Extend 2006 - Disruptive Technology
June 5-7, 2006 at the Hyatt Regency, Huntington Beach, CA
For more details, click here: http://www.extendthereach.com/extend06/
More information about the mapserver-dev