Legend icons - extra pixel in bottom-right corner

[dmorissette]

This was reported on the maplab-users list.

I think I have noticed this problem too before.  We should investigate this at 
some point, maybe a GD issue?

Peter.Bruton@ccrs.nrcan.gc.ca wrote:
> 
> Hello;
> 
> For some reason when I classify polygons, the class symbol in the legend has
> an extra pixel located in the bottom right-hand side of the symbol/image
> (see attached file).  When I set the Class's Outline colour, the extra pixel
> does not appear.  I am using the HTML legend.
> 
> Does anyone know why this occurs and how to get rid of it?
> 
> Thanks in advance.
> 
> Peter Bruton
> 

Fred Warnock wrote:
> 
> Peter,
> 
> I took a closer look at those two symbols, and I assume you set the
> symbol size to 20x10.  It's not that the one with no outline has a tail,
> it seems that there is a white line at the bottom of the icon covering
> all but the rightmost pixel.
> 
> I'm not sure what the problem is, but one of the developers is sure to
> read this ;)
>

[sdlime]

It's a problem in the polygon fill code. That code is real old. Last
modification I know of was to address performance. Can't recall who made the
changes. I'll check CVS. Anyway the problem is on the last scanline for
regularly shaped polygons. Consider the output below that you get when rendering
a rectangle as defined in maplegend.c. Scanline 16 *should* run from 5 to 22 but
doesn't for some reason. Instead only the last pixel in that line gets colored,
hence the seemingly extra pixel. In reality that's the only one in the row
that's correct. Now what's interesting is that the last line of the output has
x2<x1 which screws up the scanline writing function. If those values were
reversed then all would be well since the missing pixels would then be filled
in. I don't want to just fix the scanline function to order x1 and x2 correctly
just yet since there would be a bit of a performance hit (not much though).
Instead I'll check the fill code to see why x1 isn't always less than x2. More
soon...

Shape contains 1 parts.
  Part 0 contains 5 points.
    0: (5.000000, 5.000000)
    1: (22.000000, 5.000000)
    2: (22.000000, 16.000000)
    3: (5.000000, 16.000000)
    4: (5.000000, 5.000000)

scanline y=5, x1=5, x2=5
scanline y=6, x1=5, x2=22
scanline y=7, x1=5, x2=22
scanline y=8, x1=5, x2=22
scanline y=9, x1=5, x2=22
scanline y=10, x1=5, x2=22
scanline y=11, x1=5, x2=22
scanline y=12, x1=5, x2=22
scanline y=13, x1=5, x2=22
scanline y=14, x1=5, x2=22
scanline y=15, x1=5, x2=22
scanline y=16, x1=22, x2=22
scanline y=5, x1=5, x2=5
scanline y=5, x1=5, x2=22
scanline y=16, x1=22, x2=5

[sdlime]

Ugh. The polygon code is ugly so for now I fixed the scanline code to draw
things correctly regardless of the order of the x's passed in. Safer that way. I
left a TODO note in the code to revist the fill function with more time...

Steve

[dmorissette]

Looks great.  Marking as VERIFIED

[dmorissette]

*** Bug 251 has been marked as a duplicate of this bug. ***