Polygon's share of its rectangle inconsistent?

[David Epstein]

Thanks to Dar Scott, Craig Newman, and Jim Hurley for thinking about  
this.  I don't know why the coverage function would yield 1.0 (except  
for a very small graphic; see glitch described below).  The Dar Scott  
amendment to my function--subtracting 1 from the right and bottom of  
the rect that I survey--is, I learned, equivalent to testing whether  
"pt is within the rect of grcLID"; in other words the pixels on the  
bottom and right edge of a graphic's rect are not counted as "within"  
the graphic's rect.
I tested Dar's suggestions about lineSize and borderWidth.  Perhaps  
because I have showBorder set to false borderwidth had no effect.   
LineSize did affect the results of my "coverage" function, with  
results that are peculiar but do not solve my original puzzle (that  
reported "coverage" should not, but does, vary as I scale a shape).
I resorted to careful study of a very simple polygon, an isosceles  
right triangle with its hypotenuse toward the bottom left.  This is a  
case where I would want my "coverage" function to return 0.5, since  
half of the rectangle is covered by the visible graphic.  Rather  
amazingly, the "within(graphicLID,point)" function returned true not  
only for the points I expected, but for 5 additional diagonal "lines"  
of pixels forming a kind of border extending left and down from my  
visible hypotenuse.  This was true both for a 10 x 10 rectangle and  
for a 50 x 50 rectangle.
This makes it easy to see why "coverage" seems to decline as a  
graphic gets bigger, since these false positive pixels are a much  
larger share of a small rectangle.  But why is "within" returning all  
these false positives?  I tested the "margins" property to no avail.
One further source of difficulty:
If I define a grapic’s “points”, LC seems to impose a lower limit of  
8 x 8 on its width and height. Thus while a triangle with points 0,0  
<cr> 10,0 <cr> 10,10 <cr> 0,0 has 100 pixels within its rect,  
defining a triangle with points 0,0 <cr> 5,0 <cr> etc. results in an  
object with 64 -- not the expected 25 -- pixels within its rect.  And  
almost all of those extra pixels also register as "within" the filled  
graphic itself, so that "coverage" gets close to 1.0.

Jim Hurley’s function is very useful, but I was hoping to use “within 
()” so that I could handle graphics that are not singly connected and  
closed.  Is there some way to script a test for those cases?
David Epstein