Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

superscape

macrumors 6502a
Original poster
Feb 12, 2008
937
223
East Riding of Yorkshire, UK
Hi,

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:

Code:
sdef /Applications/Adobe\ InDesign\ CC\ 2017/Adobe\ InDesign\ CC\ 2017.app  | 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!
 

Attachments

  • InDesign.h.zip
    296.4 KB · Views: 671
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:
https://developer.apple.com/library...f/doc/uid/TP40006104-CH4-DontLinkElementID_12
Add the generated file to your Xcode project by choosing Add to Project from the Project menu and specifying the file in the ensuing dialog. In any source or header file in your project that references Scripting Bridge objects, insert the appropriate #import statements, such as the following:
#import "InDesign.h"
Finally, make sure that you have added the Scripting Bridge framework (/System/Library/Frameworks/ScriptingBridge.framework) to your project using the Project > Add to Project menu command. It is not necessary to have #import statements for the framework because the header files for the scriptable applications do that already.

From Dan_Korn at Adobe forum:
https://forums.adobe.com/message/6310513#6310513
Add Cocoa.framework to your project, then add an Objective-C source file (with the extension ".m") to the project, and at the top, #import <Cocoa/Cocoa.h>.

Those were somehow looking interesting to me:
http://www.mugginsoft.com/html/kosm.../interface_in_design_import_export_event.html
http://www.mugginsoft.com/html/kosm...terface_in_design_p_d_f_place_preference.html

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:
Code:
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:
https://forums.adobe.com/message/1961110#1961110

Hope this helps
 

Attachments

  • InDesignCS6.h.zip
    830.2 KB · Views: 544
Hi,

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:

Code:
sdef /Applications/Adobe\ InDesign\ CC\ 2017/Adobe\ InDesign\ CC\ 2017.app  | 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!


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:

http://appscript.sourceforge.net/asoc.html

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

HTH
--

(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.)
 
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...
[doublepost=1502282273][/doublepost]
Come on, Mr S—you of ALL folks ought to know better!!! :p
(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.)

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?
 
Last edited:
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?

SOAP documentation is in the InDesign Server SDK docs:

http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/indesign/sdk/cs6/server/getting-started.pdf

It can also consume XML (IDML):

https://www.adobe.com/content/dam/Adobe/en/devnet/indesign/cs55-docs/IDML/idml-specification.pdf
https://helpx.adobe.com/indesign/using/importing-xml.html

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.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.