Scripting Bridge & Adobe InDesign

Discussion in 'Mac Programming' started by superscape, Aug 4, 2017.

  1. superscape macrumors 6502a


    Feb 12, 2008
    East Riding of Yorkshire, UK

    Wonder if anyone can help me here?

    I have some Objective-C code and in part of it I need to script Adobe InDesign. I'd rather not use AppleScript if I can help it. So I thought I'd use Scripting Bridge - I know it's glitchy but my needs are simple (place a PDF) so I thought it should be up to that at least.

    I created the header like this:

    sdef /Applications/Adobe\ InDesign\ CC\ 2017/Adobe\ InDesign\ CC\  | sdp -fh --basename InDesign
    The resulting header file is, frankly, a load of *&^% - see attached file if you fancy a giggle. There are duplicate methods galore and all sorts of other horrors. There's no way Xcode will compile it.

    I guess the question is, has anyone ever got Scripting Bridge to work with Adobe InDesign, and if so, what cunning trick am I missing here?

    Any suggestions or advice would be much appreciated!

    Attached Files:

  2. organicCPU macrumors 6502a


    Aug 8, 2016
    I'm not sure if that will help, probably you'll know all this, but for me that's all completely new and you asked for any suggestion...

    From Dan_Korn at Adobe forum:
    Those were somehow looking interesting to me:

    Two observations after exporting the header file from my InDesign CS6 and comparing to your CC version:
    - My file has about 10 MB and 85 000 lines of code (attached in case you want to try if that compiles), while yours only has around 2 MB and 22 000 lines.
    - Your syntax of the header is slightly different, but that's probably just because of the newer InDesign or Mac OS X version:
    From your header:
    // An assignment.
    @interface InDesignAssignment : SBObject <InDesignGenericMethods>
    - (SBElementArray<InDesignAssignedStory *> *) assignedStories;
    - (SBElementArray<InDesignEvent *> *) events;
    - (SBElementArray<InDesignEventListener *> *) eventListeners;
    From my header:
    // An assignment.
    @interface InDesignAssignment : SBObject
    - (SBElementArray *) assignedStories;
    - (SBElementArray *) events;
    - (SBElementArray *) eventListeners;
    Maybe interesting, if you should decide to go for the AppleScript approach:

    Hope this helps

    Attached Files:

  3. hhas macrumors regular

    Oct 15, 2007

    Come on, Mr S—you of ALL folks ought to know better!!! :p

    The entire SB stack is hopless crapware, unfit for automating Adobe apps or any other serious production work. `sdp` has always royally **** itself on InDesign's SDEF, and even if you could get it to build a usable header ScriptingBridge takes a good 10-15 seconds just to build its glue tables for ID—longer than most AppleScripts take to run. Even then there's no guarantee the commands you want to use won't be borked by SB's own deliberately-designed-in #LameAndFail.

    I remember one guy who swore by SB for his Adobe automation; got upset at me for cautioning others against it. Converted his shop's scripts from AS to ObjC and SB. Then one day Adobe pushed out a minor CC update, and all his SB code completely broke. He uses JSX now. (Contrast appscript, which took under a second to initialize AND worked right too, even on the biggest/baddest/foulest of "AppleScriptable" Mac apps. Happier times.)

    Ignore SB. Ignore NSAppleScript. They're useless and a serious waste of everyone's time. Use AppleScript via the AppleScript-ObjC bridge, which lets you call into your AS code pretty much as if it was native ObjC classes and methods and is the least painful solution by many miles:

    If you need any help with ASOC, I'm sure you know where to find Shane Stanley.


    (p.s. With Apple quietly shuffling AppleScript into maintenance mode and no doubt planning some AppExtensions garbage to "replace" it, you might want to start poking at Adobe's SOAP, XML, Windows COM, and/or C++ APIs. I suspect we'll be seeing our industry move Windows-wards in the next few years—could present some profitable opportunities for canny Automators who plan ahead.)
  4. superscape, Aug 9, 2017
    Last edited: Aug 9, 2017

    superscape thread starter macrumors 6502a


    Feb 12, 2008
    East Riding of Yorkshire, UK
    Hah hah! Wotcha, fella!

    Yeah, I think the AppleScriptObjC route may be the way to go for this one. I'm trying to use AppleScript only when there's no other conceivable way forward, and most of the time I'm successful in that.

    I have a nice solution that does some fancy rendering in Objective-C, kicking out a PDF. Just need to place the damn thing into InDesign... I know Scripting Bridge has some quirks (yes, understatement of the year) but I'm thinking, "Surely, placing a simple graphic into InDesign must be do-able".

    Shows what I know...
    --- Post Merged, Aug 9, 2017 ---
    Mmmmm... I don't see the industry (for other observers, that's graphic design/print/packaging) going Windows any time soon. I've witnessed exoduses of graphic designers in the past on being told they're going Windows. However, *if* Apple left us with no AppleScript and no as-yet-unknown-better-alternative then that may start to make Windows a more attractive option.

    Personally, I'm going nowhere near C++ if I can help it, although I've had some luck with Adobe Extensions. What do you mean by Adobe's SOAP and XML APIs?
  5. hhas macrumors regular

    Oct 15, 2007
    SOAP documentation is in the InDesign Server SDK docs:

    It can also consume XML (IDML):

    Not what floats my boat, but you know me: Illustrator man t’day I die.

    Agreed on C++. (Rubberized C++, aka Swift language, already tries my patience to the brink!) But we need to go cross-platform at some point, so it's either implement support for both COM and AE interfaces or write our own C++ plugin that lets us talk thru sockets or whatever we want. e.g. Illustrator’s own AE support originated as a C++ plugin by Mark Alldritt, which Adobe subsequently bought and bundled.

    Hopefully Apple and Adobe don't move to discard AE support fast (they probably won't), which should give us a couple years to grow the business, then we can just hire a C++ dev for 6 months to come in and do the dirty for us. Till then, I’ll continue to recommend calling into AS via the AppleScript-ObjC bridge as the one officially “supported”* solution for controlling “AppleScriptable” apps from languages other than AS that reliably works.

    (Python 3 appscript, SwiftAutomation, and NodeAutomation should also work—and I believe there’s a third-party rb-scpt fork of Ruby appscript out there too—but my position on development and user support remains: none given, so don't expect them not to go titsup.)


    * Where “supported” = Shuffled off into minimal maintance mode without so much as a murmur.

Share This Page