Yeah, the lineSize idea doesn't get far (at this point) when the function is
looking at the entire rectangle and returning 100% in my case
I don't know if this is a function bug or a dictionary issue. From the
dictionary...
If the point is within the clickable area of the object,
the within function returns true,
even if another object is layered on top of the object.
If the object is a graphic,
its interior is considered to be within the graphic
only if the graphic's filled property is true
or the graphic is selected.
Since the entire rectangle seems to be the clickable area of the graphic, the
entire rectangle in my case, the second paragraph makes no sense. Also, it is
not clear to me why filled is considered and not opaque. I'm missing a lot
here.
(There are two coordinate systems used in pixel graphics (for whole number
coordinates). One puts the coordinate grid between the pixels. This makes
sense when looking at the rectangle of things and even when looking carefully
at rectangle graphics. The other looks at the points as being in the middle of
the pixel. It is off (.5,.5) from the other. If fractional pixel coordinates
or pixel-less coordinates come, the differences will be minimal. When these
concepts are mixed we get mixed results.)
Now, I'm surprised. Why are you getting about 50% when I'm getting 100%? I'm
using LiveCode 5.5.4 on OS X 10.6.8. I think somebody else was getting 100%,
too.
Because of that, or until we figure out why that is, within() might work on
your system but not on others.
I'm not sure what "singly connected" means. Does this mean a graphic can work
like several graphics?
If this does not have to work in the field, you can put your graphic on the
appropriate contrasting background and get an image of the bounding rectangle
and analyze the pixels.
Dar
On Jun 8, 2013, at 5:45 AM, David Epstein wrote:
> 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
_______________________________________________
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
