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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
