My most recent post on the CS SDK blog is about drawing--specifically, it provides routines that make drawing paths work the same way in Illustrator, InDesign, and Photoshop. (Basically, I added routines that make AI and PS work the way that InDesign's entirePath property works.)
Writing the post, thought, brought up some questions. I think that drawing paths in these applications is something that lots of CS developers would want to do--I'm thinking of both creative effects (decorative borders, etc.) and data-driven graphics. But I don't see many (if any) extensions or scripts that draw paths. What I'm curious about is--why is this the case? Is it that drawing paths is just too hard (i.e., the math is difficult or the application's support for drawing is incomplete or confusing)? Or is it that developers have so many other things to do that they just never get around to doing drawing?
So...what do you think? It'd be great to hear from the community.
I can't speak for anyone else, but I have never (or at least almost never) had the need to draw paths in real life situations. I've never gotten requests for such a thing either. Jongware seems to like playing with drawing paths, but all the examples I've seen were more "fun" than function...
I tend to shy away from maths unless I have no choice (I'm lazy...) , but I think the main reason is lack of demand more than anything else...
Thank you, Ole!
I'm very enthusiastic about your blog post and path possibilities!
I have a panel in mind that will use drawing on the document, just don't have enough time right now to make it.
Please, continue on with this topic
Hi Anastasiy Safari,
I'm working on a part 2 that covers some of the problem solving techniques that went into creating the first post. I think I'll have a part 3 that delves a bit more into the process of working with paths.
I understand Harbs' points--but I'm still puzzled about why so few extensions/scripts do drawing. Given that a.) Illustrator's charting features are not scriptable, and b.) Excel's graphics are not of publication quality, how can developers automate the production of data driven graphics? It seems to me that there must be a need here, but I could easily be wrong. (It wouldn't be the first time!)
It also seems to me that there must be Flash ActionScript libraries for creating data driven graphics for the web--if I can find some, it would be cool to provide a way to use those libraries to draw in Creative Suite applications. I'll see what I can dig up.
This actually crosses paths (pun intended!) with what I'm working on right now. I've been thinking about adding (well sort of started really) a (partial) unified scripting API for the CS products in Script Bay. Script Bay is shaping up to be quite an interesting scripting platform.
Providing simplified APIs to work wth some of the more complex aspects of scripting (especiially if it'll work cross app) would be really interesting!
Jongware seems to like playing with drawing paths, but all the examples I've seen were more "fun" than function...
This is from something I'm working on now, straying away from 'playing' to something more serious. Heavy on the Math, not so on drawing. This is Illustrator, by the way, and I'm working around its peculiar path access by feeding it straight lines only:
You might want to try the function in the blog post--it'll make Illustrator work the way InDesign's entirePath property works (feed it an array of two-item arrays, and you'll get straight lines; feed it an array of three item arrays--where the items are two-item arrays, and you'll be able to create curved lines).
Ole, fortunately this particular application doesn't need curved lines (and I shudder at the mere though it would). But it's a strange difference, used as I am to InDesign's wealth of options compared to Illy's. My Illy CHM is 332 KB; InDesign's is 2.5 MB -- 'nuff said ...
Harbs: look at the dialog. Every item is a different type of map projection -- some obscure (but easy to implement, so that's why it's in there), some need Newton-Raphson integral differencing per plotted point.
It still needs a fair bit of work; rather than drawing just coastlines as lines, which would be very easy, I'd rather draw them as fillable shapes! (With all due edge clipping done mathematically.)
This is also still using the very-low res geographic data set I composed a while ago for my Globe script. I intend to be able to use high-res data, allowing close up views of coastlines, and perhaps also country boundaries (politically loaded quagmires as they may be -- I'll make sure to add a disclaimer). But for now I'm in to my ears into 'how to rotate the poles around the globe and then project it'. I have been reading more about sin than I actually can handle, and lots of cos and tan too.
Three days ago I said:
.. But for now I'm in to my ears into 'how to rotate the poles around the globe and then project it'.
Pooh -- that was a bit harder than I thought. I even ran into one of Illustrator's hard-coded limitations -- no more than 8192 points per line. I don't think Ole can code around that.
Here is "The World", rotated horizontally about 120 degrees negative, then tilted forward 30 degrees, and then shifted along the meridian (already rotated and tilted!) by 180 degrees. Top image is a copy of Figure 56C from Gerald I. Evenden, "Cartographic Projection Procedures, Release 4, Second Interim Report", 1-Jan-2003, with the following caption:
"Figure 56: Transverse use of the McBryde-Thomas Flat-Polar Quartic projection: [oblique projection with coastlines] rotated 180◦ about pole to emphasize oceanic regions."
Bottom is my version, using NOAA's GSHSS data ("crude" resolution, but theoretically it should work with higher resolutions as well), and the same McBryde-Thomas Flat-Polar Quartic projection and rotation angles. For clarity, I also draw the circumference of the projection and the equator and 0°/180° meridian as thick lines.
(Unfortunately, the many horizontal lines you see are artefacts, caused by a 'wraparound' of the continuous-line data. I guess I'll be working on that next.)
re: "I even ran into one of Illustrator's hard-coded limitations -- no more than 8192 points per line. I don't think Ole can code around that."
I think that's a limit for entirePath only--it seems to me that I've drawn longer paths using point-by-point construction. It's pretty slow, though. Did you run into this limitation when drawing point-by-point? If so, there are some things I have to re-think.
Certainly Illustrator should be able to handle paths with more than 8192 points. When you think about the number of points that could be created by autotracing, it's hard to imagine that they'd set the limit that low.
I'm pretty sure of this! Each single path may only contain as much as 8192 points -- Illy told me so when I tried to cross that limit (CS4, by the way).
I set the first 1,000 points using setEntirePath and then used your trick to feed it the other 7,192 points. Add one more and boom!
When you think about the number of points that could be created by autotracing, it's hard to imagine that they'd set the limit that low.
you call that low? PitStop warns for paths containing more than 5000 points ...
Here is a nice image I had on my HD, traced with pixel accuracy:
The baby blue background contains no more than 1684 points, in 236 compound paths. Hey, that's funny! If I release this into separate paths, the largest is ... 1,000 points Exactly. How's that for a coincidence?
Just out of curiosity, and as part of a blog post I'm working on, I've just drawn a path containing 12,500 point in AI CS5 using the pathPoint by pathPoint technique. It's currently working on a path containing 62,500 points, but it may be awhile (overnight?) before I can report on success/failure. or I might just give up. It's been working on it for quite some time, and it's only reached the 17,500th point.:-)
No, sorry--I stopped it after several hours at around 25,000 iterations. But it hadn't crashed Illustrator at that point. More investigation is needed, or, at least, greater patience on my part (hey, I needed the machine for something else).
Europe, Middle East and Africa