Skip navigation
Currently Being Moderated

Drawing in CS Applications

Oct 2, 2010 2:07 PM

Colleagues,

 

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.

 

Thanks,

 

Ole

 
Replies
  • Currently Being Moderated
    Oct 2, 2010 2:37 PM   in reply to Olav Martin Kvern

    Hi Ole,

     

    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...

     

    Harbs

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 5, 2010 1:15 PM   in reply to Olav Martin Kvern

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 6, 2010 3:30 PM   in reply to Olav Martin Kvern

    Hi Ole,


    Interesting points...

     

    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!

     

    Harbs

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2010 2:21 PM   in reply to Harbs.
    Jongware seems to like playing with drawing paths, but all the examples I've seen were more "fun" than function...

     

    Hi Harbs

     

    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:

     

    Screen shot 2010-10-21 at 11.20.23 PM.png

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2010 2:45 PM   in reply to [Jongware]

    Looks cool!


    I shy away from math like that unless I have absolutely no choice!

     

    What are you doing with this?

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2010 3:30 PM   in reply to Harbs.

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 24, 2010 2:53 PM   in reply to [Jongware]

    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 180about 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.)

     

    Screen shot 2010-10-24 at 11.35.59 PM.png

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 25, 2010 2:41 AM   in reply to Olav Martin Kvern

    Hi Ole,

     

    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!

     

    function(){return A.apply(null,[this].concat($A(arguments)))}

    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:

     

    punchbunny.PNG

     

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 23, 2011 5:42 AM   in reply to Olav Martin Kvern

    Hey Ole,

     

    Did it ever finish?

     

    Harbs

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 23, 2011 10:47 PM   in reply to Olav Martin Kvern

    Cool.

     

    You have more patience than I would have had...

     

    Harbs

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points