Is there a way to calculate the area of a shape?

I just had a need to measure the area of AI cut-out letter templates for signage and the Cmd-Shift-Option-F12 solution worked a treat in CS4 as well!
Many thanks to all the contributors.

Just recently had to come up with a solution for a similar problem and stumbled upon this thread. Excellent info here, Thanks!

1. Make sure the background of the photo (the bottom of the chamber) is of high contrast to the plant leaves.

2. Either posterize the image in Photoshop, or with auto-trace settings in Illustrator. (see LiveTrace in the help documentation.)

3. Auto-trace the photo. Use the script referenced above to get the area of the resulting path(s).

JET

Is there a way to calculate the area of selective components in a photo?
For example, I have photos of plant leaves in a chamber, and I'd like to be able to calculate the 2D (top down view) surface area of the leaves?

>>Not a chance.

I second that. There are always lurkers who enjoy the information.

> If you want to continue off-line...

What, and have everyone else miss out on this stimulating intellectual discourse? Not a chance.

;-)

JET

JET:<br /><br />Thanks for your response! Hmmm, we seem to be drifting away from the original topic. If you want to continue off-line... let me know.<br /><br />Each of us builds our toolbox differently -- hopefully we know ourselves well enough after a while to know what works best. I generally prefer to be more adept at few distinct software packages, as opposed to trying to remember the details --and the general paradigm-- of more packages. (For the life of me, I can't retain how to use ImageReady, for example -- I just don't use it often enough.) That said, I'm OK with learning just the features I need to do my work, which places me in danger of missing out on potentially very useful tools. With unavoidable software from one vendor I find it is best to stick to the lowest-common-denominator functions and to avoid customization -- maybe a superstitious way of improving stability of the product.<br /><br />I have a history of working with code going back to the early 1970's so I'm quite OK with scripting, except that, well, the nature of coding has changed. To quote the songwriter, "the thrill is gone." There are too many (scripting) languages to learn, they are often complex, and typically there's a huge array of library functions (or equivalent) in each. A daunting task, each one of them.<br /><br />As for including functions like area in the standard interface, I think you mean the GUI, and I have mixed feeling about that, especially as features accumulate, and the GUI gets more and more difficult to navigate. If I did not have this particular problem, I'd probably be frustrated by seeing "length" and "area" functions in the GUI -- just some extra stuff that I don't need -- or some functions that I really might want to learn, but don't have the time.<br /><br />Hmmm, you would like to build really innovative features in AI's JS, and I hope you do that. (Sorry, my task wasn't really very interesting <grin>.) <br /><br />Thanks,<br /><br />Henry

> I'm not certain I could learn a radically different software package for that purpose.

I understand. To me, adding to my toolbox another software similar to one with which I'm already familiar but which has features expressly designed for the task at hand, is less work than learning a scripting language.

I'm glad that Illustrator and InDesign have their own Javascript implementations. But most of the times I use it in Illustrator, I end up asking myself why I'm kicking against the thorns? Why am I going to all this tedium in an attempt to add in a half-baked fashion a "feature" that is already standard-fare and better integrated in other programs? (I really do it for the learning exercise.) I mean, aren't WYSIWYG programs supposed to prevent us from having to continually re-invent the wheel in code?

So, yeah, at least the scripting option is there, and that's a good thing. But as you can see from the first script, getting the area of a pathItem is a simple one-statement call to a pre-defined property of a pathItem object: area. So why isn't access to that property provided in some appropriate place in the program's standard interface?

I'd much rather be using AI's Javascript to build new features like instant spherical grids or branching paths for trees and lightning. But I find that most of my scripting experiments end up mimicing features that really ought to be in the standard program anyway. (Joining paths, reversing paths, working with tab-delimited text, etc.)

Anyway, I'm glad the script helped. Maybe others will get use from it, too, and at least thereby avoing having to re-invent the wheel again. ;-)

JET