Challenge: How can we set the rect of a polygon to its visual rect?

[Wilhelm Sanke]

On Fri Aug 14, 2009, Scott Rossi scott at tactilemedia.com wrote:

> Recently, Wilhelm Sanke wrote:
>
> > Triangles, pentagons, and hexagons (three-, five-, and six-sided
> > polygons) have rects that are different from their visual rects, i.e.
> > their opaque areas when the fillcolor is set to true.
> >
> > As an example, a hexagon with a height of 200 possesses a "visual"
> > height of only 172.
> >
> > A snapshot taken from the graphic has the same dimensions, but the
> > resulting image can be cropped to the real visual height.
> >
> > Cropping however is possible only with images, so how do we proceed to
> > set the rect of a hexagon (or triangle and pentagon) to its visual rect?
> >
> > Any ideas?
>
> You can crop a snapshot image of the graphic by looking at the 
> alphaData of
> the snapshot and cropping into the image only where the alphaData is 100%
> transparent (or some other threshold you prefer).  I posted a stack that
> does this....

Scott, thanks for the answer, but this proposal is exactly what I have 
stated in my quote above. I was concerned about how to "crop" a 
*graphic* or to find some sort of workaround for this.

I have been using cropped images as masks for quite some time, one 
example being the hexagons displayed on my various "Gradient 
Kaleidoscope Galleries" (see my website below).

As regular polygons (as graphics) show this difference between rect and 
visual rect (only in the case of triangles, pentagons, and hexagons), I 
use normal "free" polygons to create triangles, pentagons, and hexagons 
as slection tools. Graphics as selection tools to cut out a section of 
an image work smoother than using a masked image for this purpose. But 
to exactly draw such a graphic hexagon requires more effort.

I wonder why this difference between rects and visual rects of graphic 
triangles, pentagons, and hexagon exists.

Is there a reason for such exceptions or do we add these inconsistencies 
to the list of peculiarities present in Revolution's graphics and image 
processing which urgently need to be eventually cleaned up?
Recently I had commented on a number of such peculiarities, which I 
suppose may contribute to the many crashes I experience with some of my 
image processing stacks.

So again, does anybody know a way - or a workaround - to "crop" a 
regular graphic to the size of its visual rect?

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>