Closed tbonfort closed 12 years ago
Author: fwarmerdam Date: 2003/09/30 - 15:36
Reproduced with this mapfile:
NAME TEST
STATUS ON
SIZE 600 450
#SYMBOLSET "symbols_1.sym"
EXTENT 532500 152180 534340 152880
UNITS METERS
SHAPEPATH "../shapes"
TRANSPARENT OFF
IMAGETYPE png24
IMAGECOLOR 210 190 190
FONTSET "msautotest/misc/fonts.lst"
LAYER
NAME buildings
TYPE POLYGON
STATUS ON
# DATA "buildings"
TRANSPARENCY 60
FEATURE
POINTS 532900 152800 5323900 152800 5323900 152100 532900 152100 532900
152800 END
END
CLASS
NAME "BAT"
STYLE
COLOR 50 200 50
OUTLINECOLOR 152 227 152
SYMBOL 0
SIZE 1
END
END
END
LAYER
NAME "roads_label"
TYPE ANNOTATION
STATUS DEFAULT
FEATURE
POINTS 533000 152500 END
TEXT "BIG_AND_small test"
END
# DATA "roads_label.shp"
# LABELITEM "Nom"
#POSTLABELCACHE ON
#TRANSPARENCY 100
CLASS
LABEL
TYPE truetype
FONT "default"
SIZE 10
MINDISTANCE 300
ANTIALIAS TRUE
POSITION cc
ANGLE AUTO
COLOR 100 100 100
OUTLINECOLOR 230 230 230
END
END
END
END # Mapfile
Author: fwarmerdam Date: 2003/09/30 - 19:28
To: support@boutell.com
Hi,
Support contract: #30723
I am trying to use gdImageStringFT() to draw into a truecolor gdImage.
The problem is that the background areas of the text are being filled in
when we should see the underlying text through them.
An example of the results not working:
http://www.camptocamp.com/~claude/mapserver/test_label_png24.png
Working properly:
http://www.camptocamp.com/~claude/mapserver/test_label_png.png
Tracking through, the problem seems to be in gdft_draw_bitmap(), used to
burn the greyscale bitmap that came from freetype into the 24bit image.
In the 24bit case, level comes out of this as 0 for portions of the bitmap
that are background:
if (bitmap.pixel_mode == ft_pixel_mode_grays)
{
/*
* Scale to 128 levels of alpha for gd use.
* alpha 0 is opacity, so be sure to invert at the end
*/
level = (bitmap.buffer[pc] * gdAlphaMax /
(bitmap.num_grays - 1));
}
Later level is inverted:
level = gdAlphaMax - level;
Then we get to this:
if (im->alphaBlendingFlag)
{
*tpixel =
gdAlphaBlend (*tpixel,
(level << 24) + (fg & 0xFFFFFF));
}
else
{
*tpixel = (level << 24) + (fg & 0xFFFFFF);
}
If alpha blending is turned on, the level causes the overlay to be treated
as transparent and no change is made (good). But if alphablending is turned
off, the output pixel is replaced by the input value even though the input
pixel is trasparent.
I *think* this is an error, but I could be mixed up about what gdft_bitmap_draw()
is really intended to do. My perception is that the function should not copy
transparent pixels to the output bitmap.
If we look through the 8bit (not truecolor) case below we see this test:
if (tc_key.pixel > 0) /* if not background */
basically, background pixels are not copied to the output. I think similar
logic should be placed in the truecolor case. Locally I patched things
to look like this, and it worked in my case. I am not completely confident this
is the right solution though (and it doesn't address the ft_pixel_mode_mono case).
if (bitmap.pixel_mode == ft_pixel_mode_grays)
{
/*
* Scale to 128 levels of alpha for gd use.
* alpha 0 is opacity, so be sure to invert at the end
*/
level = (bitmap.buffer[pc] * gdAlphaMax /
(bitmap.num_grays - 1));
if( level == 0 )
continue;
}
For my problem I will experiment with turning on alpha blending as I think
that is what I would want anyways, but I would like you to consider patching
gd for the 2.0.16 release.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
Author: fwarmerdam Date: 2003/09/30 - 19:33
I have discovered that the alpha blending flag on the gdImage was not being
set till after the outlining had been done. While I have submitted a bug
report to the GD maintainer, it seems that practically speaking, the MapServer
solution is to move the alpha blending enable call up before the outline draws.
In my test map this seems to have resolved the problem. Please rebuild from
CVS (you need mapgd.c:1.47) and see if the problem is resolved.
Please re-open if the problem persists.
Reporter: claude.philipona@camptocamp.com Date: 2003/09/30 - 08:04