AppleScript: Why InDesign Users Should Learn It
Ray Robertson and Shane Stanley have been co-hosting AppleScript Pro Sessions since 2001. The five-day training event now spends almost two days focusing on InDesign scripting. I talked with Ray so I could understand why some scripters are still using AppleScript instead of ExtendScript, the cross-platform, JavaScript-like language that works with InDesign.
David: Just to get started, could you provide a brief explanation of what AppleScript is?
Ray: Sure. AppleScript is an automation technology bundled with Mac OS X. Using an English-like syntax, you create scripts that can drive multiple applications, including InDesign.
David: Why would an InDesign user want to learn AppleScript instead of ExtendScript?
Ray: The main reason is that ExtendScript is limited to automating the Creative Suite and AppleScript isn’t. Also, if you don’t have a programming background, you may find AppleScript is a more approachable than a traditional language.
AppleScript is powerful because it works with so many applications. I have various workflows that involve data in Excel, Word, or databases such as FileMaker; Illustrator for automated creation of high-end charts; Photoshop, iPhoto or Aperture for images; InDesign for layout; and a variety of e-mail programs and FTP programs for sharing documents. All of these programs can be controlled via AppleScript, often producing publications from start to finish.
You would be surprised at the number of AppleScript users who start out only wanting to automate InDesign, then expand to other applications. Some companies have very sophisticated workflows using iPhoto, helping the photographers on the front-end and the production people on the back-end. Pretty amazing for something which is basically free. And often scripters who start out with work-related tasks end up using AppleScript at home to customize iTunes and other consumer apps. That’s not possible with ExtendScript.
The other reason is approachability. I’ll be honest–it’s debatable whether AppleScript is easier to learn in the long run than ExtendScript, but a typical InDesign user without a programming background will find AppleScript more approachable. In my seminars, I can show a line of AppleScript code such as “set stroke weight of every rectangle to 2.0″ and I think most InDesign users will understand what that does. Not everything is so easy to read, but the English syntax removes some initial hurdles for first-time scripters.
I find that most InDesign users live in a deadline-driven world. It’s unlikely that they can set production work aside for several months and learn a scripting language. Instead, they write bits and pieces of code, and then may not be able to look at it again for six weeks. The fact that AppleScript’s syntax is more readable to most people means they can pick it up again quickly, and continue working on an automation project until the next deadline. Eventually, they get to the point where they can automate a six-week production cycle into a two-day one. I’ve seen it time and time again.
David: Let me play devil’s advocate for a minute. Why do you think an InDesign user might want to learn ExtendScript instead of AppleScript?
Ray: Well, the obvious answer is that it’s cross-platform and AppleScript is Mac-only. There are some companies where the same person is responsible for automation of InDesign under both Windows and Mac, and it is great for trainers and authors like yourself who want to distribute just one set of scripts. If I had a programming background (which I don’t), I might prefer the traditional structure of ExtendScript. The flexibility of AppleScript’s syntax can drive traditional programmers a bit crazy. And if I had a background in JavaScript, I’m certainly going to want to use ExtendScript, since it is Adobe’s proprietary implementation of JavaScript.
David: Do you think AppleScript is as powerful as JavaScript, at least on the Mac?
Ray: AppleScript definitely has some limitations. It doesn’t have the functionality of JavaScript for dealing with text. For instance, AppleScript has no built-in function for sorting. But since it can drive other applications to do sorting—Excel, the freeware TextWrangler, or the Unix shell itself—there are numerous ways to get the task done.
Of course, when Adobe first introduced ExtendScript, some developers questioned why it was based on JavaScript, instead of more modern languages like Python or Ruby. I’m only guessing, but perhaps it was because JavaScript was so popular on the web.
One word of caution, though: I’ve seen web developers attempt to use ExtendScript to automate InDesign, and some underestimate the depth of InDesign itself. An InDesign user already understands the basic object model: There are documents, which have pages, which have text frames or rectangles, which may have images or other objects, and may be grouped, or stories which may be linked. And all of these objects have many, many properties, such as the stroke weight, color, etc. If you already know InDesign, you are halfway to the goal of learning how to manipulate all of its objects via scripting. That’s why I think the best scripters usually come from an end-user background.
David: Have you considered switching to ExtendScript?
Ray: Briefly. The appeal of more income from cross-platform development was definitely there. But I’m a Mac user, and I decided that even if I wanted to limit myself to the Creative Suite, could I really avoid having to troubleshoot issues under Windows?
The other thing was the development environment. In the AppleScript world, I’ve been using Script Debugger, a third-party editor from Late Night Software, for years. When I looked at the editor Adobe includes for ExtendScript I just couldn’t imagine switching. I’m sure the editor has improved since then, but I doubt it is close to the sophistication of Script Debugger.
David: You’re doing a week-long AppleScript seminar soon. Do you typically have many InDesign users at your training sessions?
Ray: Oh yeah! Typically over 90 percent are InDesign users, which is a big change from just five years ago. Adobe did a great thing in making InDesign the most scriptable application on the planet. About 99 percent of it is scriptable, so scripters can tell people with assurance that a particular task can be automated. That has never been the case with QuarkXPress.
I’d like to think that scripting support played a role in the switch from QuarkXPress to InDesign. Power users usually lead a migration, and scripters are definitely power users. We’ve had QuarkXPress users come to our session, see InDesign’s AppleScript support, and go back and convince their companies to switch. That’s still happening today, though now we have more InDesign users who go back and convince their companies to upgrade to the latest version.
David: Is there anything new in the AppleScript world?
Ray: With Snow Leopard, we now have AppleScriptObjC, which gives us unprecedented power. Now AppleScript has access to Cocoa, so we have access to much of the same functionality as other Mac developers. It’s pretty amazing that an InDesign user on a Mac with no programming background can start writing a few simple scripts in a friendly syntax, and eventually develop full-fledged Cocoa applications. The sky is really the limit now.
Ray and Shane will be hosting the next AppleScript Pro Sessions April 12-16, 2010, at St. Pete Beach, Florida.
I love applescript and I’m into ePublishing industry, I have been developing applescript for Indesign, implemented in our production. I have been using it for the past 8 years. When compared to it support to Quark and Indesign, The later leads…
By well understanding Indesign, their classes and objects one can develop a script which can be automated in their workflows.
My recent developments
1. Create Hyperlinks for every URL found in the document (The logic here is using GREP to find out the valid URLs, thanks to prior GREP URL discussion in this forum)
2. Create Bookmarks for a Particular Chapter Title style in a Document
3. Every Page-end is marked with the hidden (Invisible character), so that if exported to xml, page break tag can be easily implemented.
4. Replacing the entities found in the document by a equivalent UTF-character, and so many…
Thanks Indesign to give such enormous capability to automate the tasks through Apple Script.
Beloved,
AS Guru
We use AppleScript instead of ExtendScript specifically because we can automate many diverse applications and build workflows enabling them to work together to accomplish a task.
Could we learn another language? Probably. But it would be much more difficult to learn for the same reasons Ray gives here. And it would never provide the depth that AppleScript provides because it could never work outside the Creative Suite.
Not having support for Windows is trivial. I suppose there might be some small things that we could automate for our (mostly Windows) InCopy users. But composition, art, photo, tracking, and prepress stand to gain way more benefit than we give up with a few Windows users not having access to AppleScript.
Some will dismiss me as just some cranky, opinionated programmer, but good grief Applescript is poorly designed, weirdly limited language. I’m all about getting work done by whatever means necessary, but if the future of productivity on the Mac is Applescript, then that is a problem. If Applescript is all you know, and you’ve found some ways to be productive with it, then great. But in my view Apple would do well to create a portal on OS X by which people could use Python (which comes pre-installed on OS X) to control Creative Suite and other applications. This already exists on Windows (heresy, I know). It is called COM. We have a big advantage in that our typesetters use InDesign on Windows rather than on Mac. With Python on Windows I’ve got full access to the Creative Suite and other applications, plus full access to the file system (unlike with Javascript), plus an instant command-line interface, which makes it easy to add meaningful interactivity to scripts, plus a language that is well-designed and highly extendable through its standard library. These are serious advantages. I did experiment with py-appscript to see if it gave the same kind of power COM gives. Unfortunately it doesn’t.
Even if for some reason you love Applescript, you would stand to benefit from the kind of thing I’m describing. Believe it or not Python is easier to understand than Applescript, it is way more powerful, and you can write your scripts in about half the keystrokes as what Applescript requires.
I once did some scripting in Extend Script (a script to break a multi-column text frame into individual ones because that was something I found myself doing manually way too often) and I found Extend Script was the only option that allowed the script to be integrated into InDesign’s menu system, plus it was the only way to make it cross-platform.
Personally, I didn’t like Extend Script at all. I have some C++ programming experience, and I found that the language made it extremely hard to write clean, object oriented code, and I had to battle all sorts of conflicts when loading multiple scripts (integration into the menu system requires them all to run in the same engine). I quickly gave up trying to share pieces of code (for instance I wanted to use my localization code in more than one script) because all I got was naming conflicts and other weird problems.
The syntax to make stuff object oriented is not only counter-intuitive and nonsensical, it also feels entirely like one giant hack. I was under a deadline on a project, though, and I didn’t have time to learn everything about the scripting system, so maybe it’s really not as bad as I remember it, but still, I didn’t like it at all.
I wish Adobe integrated Python into the Creative Suite instead. It is extremely simple to learn for beginners (I’d say somewhere between Apple Script and Extend Script, if not on par with Apple Script) yet extremely powerful for experienced programmers (much more so than Extend Script), code is very short and clean, it is cross-platform, and there is a multitude of existing extensions available for database access, math, image processing, internet communication, access to Windows API/Cocoa etc., so there are very few limits to what can be achieved with it. There are also options to communicate with other applications via COM or their native Apple Script interface.
The only advantage I see in Apple Script is that it does not scare people off initially as much because the syntax looks so natural, but I doubt that on the long run “rectangle.strokeWidth = 2.0;” is much easier to comprehend than “set stroke width of the rectangle to 2.0″. I even find the former mach quicker to understand when going back to existing code.
@Pat: You were obviously a bit quicker than me, but it’s nice to see that we agree
On OS X there is something called Scripting Bridge that allows you to use the Apple Script APIs of any application in Python. See here for example. It comes with the OS, so there is no need to install anything.
The disadvantage, though, is that menu system integration in InDesign/InCopy is only available via the horrible Extend Script language, and as I said, since all menu integration scripts run in the same engine, all sorts of issues arise from that. The only way to get Python menu commands into InDesign is if Adobe integrated an interpreter into InDesign.
I use AppleScript in several work-flows daily, but I favor using ExtendScript even if slightly limited on a mac.
Because it is an extension of JavaScript, and shares constructs with ActionScript, HTML5 and AJAX implementations, it allows me to study only one language for several usages.
With the addition of PatchPanel and SwitchBoard (from Adobe Labs) there is another layer of interaction available beyond the scope of just the Creative Suite that makes up for some of its Mac based limitations.
But the main proponent of my personal decision is because it is cross-platform. Much to my dismay, an increasing number of my clients do not have the luxury of using the mac platform.
Peter alludes to one disadvantage to the Python-on-Windows scenario I was describing–namely, that I can’t integrate Python scripts into the InDesign menu system. I have to call them from the command line, which is easy for me because I’m used to that sort of thing. But others might find that bothersome.
So I echo Peter’s wish that Adobe would integrate Python into into Creative Suite.
@Peter: Evidently we were typing follow-ups at the same time as well
I’ll have to look at Scripting Bridge. My only attempt was through py-appscript, which seemed to be mashing Python into Applescript, which ended up limiting Python.
@Pat, I agree. AppleScript is unwieldily. The code is hard to read, write, or do anything that I typically want to do. Typically I’ll have an AppleScript just launch a Perl or Shell script that runs in the background to do what I need.
Okay, so I am an InDesign user who is very interested in learning AppleScript. Where should i start?
Oooh — Python!
Anything but VBA should be better, but if Adobe ever polls on this, Python would get my vote as well.
How does one go about learning AppleScript, JavaScript and Python? What’s the beginning steps. How do scripters usually start out?
For those wanting to know more about AppleScript, see a book review and other links (posted in comments) which David did here.
There are many other books on AppleScript, and I would also recommend the website macscripter.net for all kinds of info.
As for InDesign itself, see Adobe’s ID CS4 AppleScript
Guide. There’s also a tutorial PDF by Olav Kvern, I believe. Plus, Adobe’s user forums have a section on scripting InDesign.
There are many other resources, and if anyone wants more information about our training event, I will post it here.
The primary reason I use Applescript in a publishing environment is that I know it. I’ve been scripting since its release in 1993, and was working in Hypertalk before that. I don’t have time to learn a new language when I already have so much code written and ready to plug into new or existing workflows.
Our current scripted workflows involve InDesign, Photoshop, Illustrator, Mail, Extensis Portfolio, iPhoto, Excel, as well as text manipulation and data analysis. The list of scripts I’ve written over the past 16.5 years is far too long to post here…
Python users,
People who are much smarter than me say it is a great language. Although I hear almost as many requests for Ruby. And yes, as mentioned here, people even talk about Perl and shell scripts.
But Adobe is already supporting three languages in InDesign: AppleScript, ExtendScript, and VB or whatever the scripting-language-of-the-moment is under Windows. What do you think the chances are that they will add Python?
I have a different request: Allow us to use the tools of our choice on each platform, but provide a way to put a wrapper around it so it easily can become an InDesign plug-in. For instance, you can choose a variety of languages, including AppleScript, to create an application using Xcode on a Mac. I can create a great interface for an app which will drive InDesign. Wouldn’t it be great if there was an easy way to convert that into a plug-in?
That’s a request I made long ago. I’d rather Adobe take advantage of the tools available on each OS, rather than developing their own language and editor.
Peter,
I’d appreciate a little more information on this:
“The disadvantage, though, is that menu system integration in InDesign/InCopy is only available via the horrible Extend Script language”
With AppleScript, I can create menus and menu items in InDesign CS3 and CS4, attaching scripts to each. I can attach scripts to existing menu items. I can attach scripts to certain events, such as closing a file (checking for modified links at that point, for instance). And, of course, I can put AppleScripts in the Script Panel and assign keyboard shortcuts to them.
Are you talking about something beyond that? I know there are some ExtendScript-only features in InDesign, and I’m not aware of all of them.
Peter said:
“The only advantage I see in Apple Script is that it does not scare people off initially as much because the syntax looks so natural, but I doubt that on the long run “rectangle.strokeWidth = 2.0;” is much easier to comprehend than “set stroke width of the rectangle to 2.0?. ”
A valid point which many users of multiple languages have made to me. It is a personal preference.
But getting beyond that point of “being scared of initially” is a big step. Some AppleScript users do go on to learn other languages, but many find it powerful enough for what they need to do.
I know people who might prefer to use terminal and shell scripts for all file manipulation instead of Apple’s slow-by-comparison and “ancient” Finder interface. But it is the Finder’s interface which draws the average new user onto a Mac, and year-after-year I see the same happening with AppleScript and InDesign users.
@Ray: This may well have changed or, even more likely, I may not even have been aware of the possibility. My understanding was that it was only possible to create menu items from Extend Script code on application startup since only Extend Script would allow you to run scripts in InDesign’s session engine and thus keep the event handlers in place (for graying out the menu item if nothing is selected and for responding to clicks on the item etc.). This may be entirely wrong, and I didn’t check the Apple Script documentation, but I distantly remember something in the CS3 scripting guide about something related to the menu things being Extend Script only. But again, that was several years ago and I’m probably entirely wrong.
@Peter: Okay, I looked at Scripting Bridge a bit. From the examples on the site you linked to it looks to me like Apple Script or OSA is functioning as an intermediary between Python and InDesign, such that you end up more or less using Python to control AppleScript to control InDesign. With COM you’ve got full access to the InDesign object model transparently from Python. There is no mediating language. I’m wishing for something closer to that on the Mac. Also, the site talks about how “expensive” these calls are, which I’m assuming means it would be a lot slower than COM. Still, I’ve borrowed a Mac from our design department, and I’m going to check it out further. Thanks.
@Ray: I really hope Adobe is open to integrating Python (or Ruby for that matter). It is easy to show the big upside to it, so hopefully they will consider it.
Look, I don’t mean to just rag on AppleScript. If I had to get work done in InDesign on a Mac, I would likely use it for some things, use JavaScript for most things, and keep praying for the day when Adobe integrates Python. So I’m not saying it is worthless. But I will say that it is unfortunate if people view Applescript as “less scary” than Python or even Extend/Javascript (and I have no love for Javascript). The attempt to make AppleScript sound like English makes it seem less scary up front but ends up backfiring in the long run: if you’re doing something that has any complexity to it, in my experience AppleScript is harder to write, harder to read, and harder to troubleshoot. Plus when you learn programming by learning AppleScript and then need to learn another language, you find that very little of what you learned about AppleScript transfers to the new language. Aside from a BASIC class that I took in high school and then forgot, AppleScript was my first language (OS 7, 8 days), so this has been my experience. Maybe others have had a better experience with it.
I work for a monthly volleyball magazine here in Italy. My workflow includes:
– on receiving the photos I process them through Photoshop resizing them to 300 ppi and converting to CMYK; this is done dropping the pictures folder on a script I’ve made.
– then, text cleanup time, through GREP and a bit of Applescript.
– in the end, before packaging the files for the print facility, a great script I wrote (in years of refining and trial&error sessions…) that analyzes the pictures in the actual indd doc, and, if needed, opens them in PS, squeeze them to avoid disk waste (like pictures appearing in InDesign at 15%), save them, update them in the doc and package the whole thing.
I can’t tell you how much time I save every month…
Long Live Applescript!
g
Oh, I forgot:
then, always through Applescript, send them to the printer over http://ftp...
g
AppleScript has greatly improved productivity and quality at our facility. I also want to recommend the AppleScript pro training by Ray and Shane. They are incredibly thorough and the sample scripts are extremely helpful!
Part 20 of Apple’s domination of the world!
“we’ve ruined music, film, made the audience buy our latest gizmos and now we will ruin indesign”
yey for apple
If you are running scripts unattended (not launching from the Scripts panel), then I much prefer AppleScript over ExtendScript. Although I do like the JavaScript syntax, AppleScript gives you benefits such as saving your scripts as application bundles, idle scripts for timed execution, and the ability to integrate several apps like InDesign together (not to mention shell commands, and Finder events) all within a simple Script Editor window. It’s just too versatile not to use for most tasks.
If you simply use scripts that will only be executed from within InDesign, and will only access InDesign page items, then ExtendScript is probably fine (just my two cents.) My workflow projects are a bit larger, so I primarily use Java, but then make AppleScript calls from Java to access InDesign.
Another benefit of AppleScript that some may feel is a hindrance, is that AppleScript has a very strict syntax. This can be frustrating if you don’t like the syntax, but it does force consistency and makes it easy to read scripts written by others.
In our Production department it’s 99% AppleScript and 1% javascript. I have a limited amount of time I can spend on scripting. It’s like cooking a complicated dish for dinner but having no appetizers, side dishes, or dessert. With AS I can do all that in the same amount of time.
Not to mention being able to round trip between the OS, FTP, Filemaker, and InDesign.
Rik,
Thanks. I was hoping someone else could talk about the advantages in how AppleScripts can be saved. To your list I would add:
1) Droplets—Applications which process files dropped on them. Such a simple interface, but still one of the most useful around.
2) Run-only formats. These are scripts which can’t be edited. Not only useful for consultants wanting to protect their code, but others wanting to prevent accidental changes in the field.
I had really hoped more ExtendScript fans would participate in this discussion. I’d like to understand how it is supported in other Adobe applications, and how complicated it is to address more than one application in a single script.
I think Illustrator and Photoshop support the same three scripting languages as InDesign, and that Bridge is ExtendScript-only. But Acrobat seems to support JavaScript (not ExtendScript), and, there is still some minimal support for AppleScript. I have no idea about support in other Adobe products, since I can’t even keep track of all of Adobe’s products anymore.
In terms of inter-application scripting, Applescript hops merry circles around Javascript (slash Extendscript). It’s really THE big plus for that language — and, mind, Adobe didn’t even have to add very much — just the interface to InDesign. The rest comes from the OS.
.. It’s so unfair ..
Coming from a Windows background, I quickly learned to steer well clear from VBS (where others do make very good use of it — viz. Robert Tkaczyk with his site http://www.adobescripts.com –, so it might just be me, after all).
My choice for Javascript, which I didn’t really know that well, apart from some hacked-together web snippets, was vindicated when I found a new job in a primarily Mac environs. To my surprise, the new colleagues didn’t use Applescript that much, save for the occasional downloaded “might be handy” FTP droplet or something. In no time I found myself writing scripts to streamline their work-flow, starting with repeated Search-and-replace thingies, and eventually culminating into the one-day-one-book system that is the backbone of the firm. And it all works OS independent, which is a plus in a market where Word and PowerPoint reign supreme.
Adobe might decide to expand their range of supported languages (which I would applaud), but as long as Windows itself and its applications do not support scripting — at least, not to the extent as OS X does –, it’s really only a matter of programming preferences.
Ending on a happy note (since this is InDesignSecrets, and not IllustratorSecrets or PhotoShopSecrets): the range of supported commands, methods, and properties for InDesign is the largest in the entire suite.
I’ve always wished InDesign and Illustrator were “watchable” either by AppleScript or, like Photoshop, with JavaScript (ScriptListener plugin).
I’ve never liked Adobe’s convoluted, hard-to-understand, cryptic AppleScript dictionaries. When I script Photoshop, I use ScriptListener to grab and create JavaScript code (which I know enough to edit, but not to write) and use “do script” in my AppleScript to make the surrounding bits. As a plus, the JavaScript+Photoshop seems to run faster (“more native”?).
I’d probably do more AppleScript tinkering with InDesign or Illustrator if they had their own ScriptListener (or were truly watchable by AppleScript, which is incredibly rare these days). Right now, it’s just too daunting to slog through.
Anyone know why “recording / watching” by AppleScript has all but vanished from software? THAT would make the newbie scripter’s life easier (and let them learn easier!).
As for AppleScript programming not being applicable to other languages, I wouldn’t say that. I came from a programming background, and AppleScript is no better or worse than others…all of them are just learning different syntax, idioscyncracies, and efficiencies. You want to see “odd,” try line-BASIC sometime, and even that carried-over well to modern languages (and made you appreciate them!).
wordbird, Eugene, anyone else wanting to learn AppleScript … if you have a chance to go to the AppleScript Pro session that Ray and Shane are running in April, then GO!
If you don’t know AppleScript, they will give you the grounding; if you know AppleScript a bit, they will take you on to the next level. They are THE experts in the field.
“Anyone know why “recording / watching” by AppleScript has all but vanished from software? THAT would make the newbie scripter’s life easier (and let them learn easier!).”
I can only assume that recordability is just too difficult to implement. Very few companies do it now. It makes sense that ScriptListener works in Photoshop, since it has much less scripting support, and what it has mainly seems to be based upon Actions. So recording Photoshop is easier.
As for InDesign’s dictionary, I wouldn’t fault Adobe at all. In fact, the InDesign dictionary contains a lot more helpful info than many others. The scripting support in ID is so HUGE/AWESOME that any dictionary or documentation is going to be overwhelming initially.
TIPS:
* Get Script Debugger. Its various dictionary views, including the Explorer, really help with learning about how to work with an application.
* Use search in a dictionary. Search for commands (such as “place”) or objects (“text frame”). Debugger helps here as well as at the bottom of an object, for instance, it lists “Where Used”. One of the difficult things about AS is knowing where to direct the commands. This feature helps a lot.
* With ID, if you can’t find a property, it’s usually in a preference. ID is just so complex that they had to store some things in preferences. For example, if you want to change the number of columns in a text frame, you don’t address the text frame, you address the text frame preferences of that text frame.
That last one is an extreme example and may scare some newbies away, because it really doesn’t follow the UI. But searching dictionaries helps.
Anyway, there’s a reason Shane flies all the way from Australia to do these sessions once a year or so. No one is better at explaining how to work with AppleScript dictionaries, and no one outside of Adobe knows more about InDesign scripting. End Shameless Plug.
Ray asked for ExtendScripters to get involved, so here goes…
There’s no question that when you need to do things outside of the Creative Suite AppleScript (or VB on PC) is the only way to go. Even something as simple as opening a web page, or sending an email is impossible in ExtendScript alone. Fortunately, there is the ability of running AppleScripts or VB scripts from ExtendScript for these cases.
Why do I use ExtendScript over AppleScript (even though my platform of choice is Mac)?
1) Cross platform compatibility: I have clients both on Mac and Windows. I need to be able to write scripts which work no-matter what platform they might be using.
2) I found ExtendScript much easier to understand. This might sound surprising, but even though AppleScript has an English sounding syntax, it is definitely NOT English, and the syntax is not the way a person naturally talks. I find AppleScript to be MUCH more verbose than ExtendScript. JavaScript is a very simple language and very logically structured.
3) There’s much more JS guys on the scripting forum than AS guys, so you usually get quicker help with ExtendScript.
4) There is a lot of general purpose help/tutorials out there on the web (since js is extremely popular on the web) which are very applicable to scripting Adobe programs.
5) I recently got into ActionScript, and I’m very happy to have a solid grounding in JavaScript, since that gave me a big jump-start on learning ActionScript.
The fact of the matter is, that the longer I do this programming stuff, the more I realize that you really need to know a bit of everything to be prepared for any kind of job…
It takes some courage to say anything in this thread, because I’m a Windows user. But because I was asked to comment also, here we go. I use ExtendScript. Before that, I used Delphi (Object Pascal; in Delphi you can use the Visual Basic type library). I did some other programming in Delphi and C(++). I switched to JavaScript so my scripts would be platform independent and that has worked very well the last years: a lot of Apple folks have used my scripts.
In general I agree with Harbs comments. My opinion of AppleScript’s syntax is even worse than his: it is a complete mystery to me why people would like it: it’s a completely failed attempt to make programming look like having a conversation and makes programming in it a very nasty experience.
When calling OS specific things you can use visual basic on Windows and AppleScript on the Mac. The first is at least a bit understandable, the latter is for most Windows users/programmers a total mistery.
Sorry folks, but that’s my opinion as a Windows user.
Teus
I agree with what both Harbs and Teus have said. I used to use AppleScript with InDesign and I could never get my mind around the syntax. It became a regular thing that I would post an explanation of my latest issue and then I’d wait for Shane to wake up in Melbourne to get help.
I don’t know why I took to ExtendScript like a duck to water but I was just comfortable with it from the start. Even though, looking back at those early scripts, I’m astonished at how much I got done knowing as little as I did about the language.
I note comments in the thread that you can’t access the file management from ExtendScript. This isn’t true, although working with files in the one area where you’re going to run into platform differences.
And while Harbs is right that you can’t open a website with ExtendScript, you can in combination with InDesign. I do it by creating a temporary InDesign document, making a hyperlink URL destination, using the showDestination() method (then closing without saving the temp document).
I have written a script that used BridgeTalk to work between InDesign and Photoshop. It was an awful experience and there’s no doubt that AppleTalk is vastly superior for that kind of activity.
Gathering data from other application’s files is also fairly straightforward if you can place those files in InDesign. Mind you, when the original is in Excel, you can find yourself having to work with huge tables which isn’t always fun.
HTH.
Dave
I switched from AppleScript to JavaScript a few years back mainly for AppleScript’s almost entire lack of inbuilt support for XML, trigonometry functions and string handling. I find that I need all of them a lot and I can’t assume anything like LateNight’s osax’ to be installed on all the computers the script is meant to run.
I found an interesting approach to open a website in ExtendScript:
function openWebsite(ws) {
if (File.fs == "Macintosh") {
var tempFile = File("~/Desktop/tempurl.webloc");
tempFile.open("w");
tempFile.write("\
\
\
\
URL\
"+ws+"/\
\
");
tempFile.close();
tempFile.execute();
for (var aux = 0; aux < 100; aux++) {
$.sleep(10);
}
tempFile.remove();
} else {
var tempFile = File("~/Desktop/cuppascript.url");
tempFile.open("w");
tempFile.write("[InternetShortcut]\
URL="+ws);
tempFile.close();
tempFile.execute();
for (var aux = 0; aux < 100; aux++) {
$.sleep(10);
}
tempFile.remove();
}
}
For my experiences with BridgeTalk “ghastly” is too strong a word. A devil to debug but running well as soon as you got the hang of it.
Especially since my recent attempts to script Apple Mail (using AppleScript of course) I must say that I do not miss the mysteries of that language.
Sorry about the code mess in the previous post. I uploaded the snippet here.
I had forgotten that I have my “go to URL” code in my snippets file. Here’s the code (let’s see if I have better luck than Gerald):
function goToURL(theURL) {
var aDoc = app.documents.add(false);
var myDest = aDoc.hyperlinkURLDestinations.add(theURL);
myDest.showDestination();
aDoc.close(SaveOptions.no);
}
Dave
Gerald,
Forgive me, because I’m going to be totally unfair. The AppleScript equivalent of your code is:
open location “http://www.cuppascript.com”
Now I recognize that you are posting a workaround since ExtendScript can’t access other applications. You seem to be creating an internet shortcut, which works well.
Because this post is so unfair, I could post some code later which is more convoluted, such as some the subroutines available to get around AppleScript’s math shortcomings.
But I will try to get back on the subject of InDesign first. I’ll see if I can post an example of both simple and confusing AS syntax directed at InDesign. Just let me think on that a bit to come up with both extremes.
And yes, Mail’s support for AppleScript has gotten worse over the years. Apple’s track record with support for AppleScript in its own apps has much room for improvement.
I have used both an approach similar to Gerald’s and open location in a doScript.
open location is much more elegant, but it will only work if there’s no modal dialogs open. Then File.execute() is the only way to go…
This discussion must be really boring for non-scripters!
Just a clarification on the previous comment:
open location in a doScript will not work while a modal dialog is open. I believe it will work in a regular AppleScript…
@Dave: That’s a nice hack! (But even you must admit it’s a hack…)
Of course the issue with modal dialogs applies to your hack as well (and perhaps even more so…).
A point that’s worth making is that InDesign scripting is not limited to only AppleScript, VBScript, and ExtendScript/JavaScript. Any scripting language that can connect with the platform standard “channel” for automation can be used to drive InDesign (i.e., Apple Events on the Mac OS and COM in Windows).
It’ll be a little bit harder–some languages, such as C#, will run into difficulty due to their stronger typing requirements–but there’s no barrier there.
The idea is to do just what Ray said–let you choose the tools you want to use. I hope that we can keep it this way.
Regarding the InDesign dictionary/object model–anything that you can do that changes the InDesign data model can be scripted (if not, you’ve found a bug). None of the other applications in the Creative Suite have this kind of coverage. Recording would be nice, but completeness is far more important. That said, recording has been on our wish list forever, but never seems to make the final cut.
Thanks,
Ole
Obviously people have strong opinions as to which language they prefer. I think that’s only natural. We all have personal preferences, and each language has advantages and disadvantages. But whichever you choose, life is better with scripting than without! As “bad” as any of these might be, let’s not scare off anyone from learning scripting. Now that I know scripting I can’t imagine life without it.
For me the choice was simple… Learning any computer language is not a trivial task. I didn’t know AppleScript, but I did know JavaScript from my web experience. So when Adobe added support (I think it was back in InDesign CS) I was ecstatic. Finally this was something I could do without having to learn a whole new language! I was very happy for cross-platform support. For those of us who make commercial scripts that we sell, that is a very important advantage.
To anyone reading this that is new to scripting, just jump in and try it. It might not be easy at first, but it is worth it in the end.
I absolutely agree that the benefits of scripting are such that anyone who just dives in wherever they can are going to reap big benefits, so go for it.
To the Windows users out there, if you happen to know VB already, believe it or not, probably the fastest way you can become conversant with the InDesign object model is by writing your first scripts in Microsoft Word’s Visual Basic Editor. Once you create a reference to the InDesign object library, the Visual Basic editor will list auto-complete options for the entire InDesign object model as you write your code. You can learn the object model very quickly that way, and yes, you can write macros that control both InDesign and any Office application simultaneously. Once I found out I could control both Word and InDesign from Python, I was glad not to use VB anymore
, but my I owe a lot to VB for helping me learn the InDesign object model quickly. It is worth checking out.
What a great post. Listening to other peoples experiences in this world.
I started off (trying to) learning AppleScript, as I have always loved the Mac experience. When it became apparent I may need to script for PCs I moved to Javascript (ExtendScript). That was the best move I have made! working with text mainly in my early days, the standard Javascript string methods I could use in Extendscript were huge, and heavily supported on the web. Another thing I stumbled across was for some reason, and I was on a G5 PPC platform, a complicated script could take up to 20 mins to complete. Seems like a long time, but the manual method was 3-4 hours….. with human error thrown into the mix. The same script, running on an older PC, Win 2000 would take 6 mins or less. So obviously we ran this particular script on the PC for convenience. Could not have done that on AppleScript.
I am blown away by the support found in the Adobe Scripting Forums, and I have never come away thinking my need has not been met, so I want to take this opportunity to say a big thanks to Dave (so instrumental in my early days), Ole, Harbs, Jongware, Peter and others for your amazing knowledge, and freely passing the skills down the line.
Bring on CS5!
Roy
There are some good points made for and against AppleScript. One note, the “convoluted” terminology for InDesign and at times confusing or undocumented functions are not part of AppleScript but Adobe’s implementation of it.
It would be nice to see Apple put more advanced math functions into AppleScript as well.
One advantage that I didn’t see mentioned is that you have access to all the shell commands available in the OS X system. I was working on a contact sheet application and using the Finder commands for getting a long file list from nested folders of specific types took quite a while. I had some help on the MacScripter site to rework it using shell commands and it took considerably less time.
And as I believe someone else mentioned if you need something that is not supported in AppleScript that is available in javascript then you can use the do script command in the AppleScript to accomplish this.
Of course the opposite is also true, so you can run shell commands from Javascript using doScript as well…
There is extensive File support built into ExtendScript, so it could be that ExtendScript might even have an advantage there…
I think you misunderstand how inter-process communication works on Macs. GUI processes communicate with one another via Apple events, and Apple events are based on RPC+queries, not OO like COM. The Apple event APIs provided by the likes of InDesign consist of a fairly thick View-Controller layer which translates those queries into operations on the underlying Model layer. It’s actually quite an elegant and capable system when it works (I build heavy-duty Mac-based workflows using Python+appscript myself), but it’s a bear for application developers to implement and documentation (both general and application-specific) is notoriously inadequate.
Hence the very different look and feel of the Apple event APIs compared to the COM APIs: it has nothing to do with the language you use; it’s the applications themselves. Appscript, for example, is just a thin wrapper around the Apple Event Manager API that adds some syntactic sugar to make these queries easier to write; the actual semantics though are straight out of the Apple Event Manager. (Scripting Bridge tries to dress up Apple events to make them look more Cocoa/OO-like, although this tends to cause more hassle than it solves.)
FWIW, you can find various documentation and links on the appscript website that will help you understand how Apple event IPC works. Dr William Cook’s HOPL paper on the development of AppleScript is well worth reading for the insights it provides, and Matt Neuburg’s Scripting Mac Applications With Ruby book has a slew of InDesign scripts in the Examples chapter.
(blockquote tag fail; that was a response to Pat LaCosse)
The blockquote tag works, but the formatting makes it very not obvious…
Wow! appscript looks very cool! Thanks for the link!
has said:
“I think you misunderstand how inter-process communication works on Macs. GUI processes communicate with one another via Apple events, and Apple events are based on RPC+queries, not OO like COM.”
You are right. I’m beginning to understand it more, but especially when I tried appscript a year ago, I didn’t understand it. I came to it expecting to find something closer to what COM enables. Based on my limited knowledge I perceived that instead I was just sending messages from Python to InDesign via AppleScript. I think that was just my dumb way of describing the difference that you have more accurately described. At the time I had just written a Python program to pull data out of Word manuscripts and create hundreds of Jumble puzzles in InDesign. It took about half a day to write the program, and it ran very fast. Afterward I tinkered with replicating it for Mac via appscript. I didn’t get very far, because I found it frustrating and it seemed to be a lot slower than COM. Still, I want to learn more about what possibilities exist there, so thanks for the links.
Am I correct in my perception that these differences mean there wouldn’t really be a way to develop cross-platform ID-scripting solutions using Python right now?
Pat
has,
I was just reading the Appscript documentation again, and you are right that I was not understanding it well.
I guess I was especially confused by the role ASTranslate plays. The ASTranslate description reads as follows:
“A simple exploratory tool for translating application commands from AppleScript to Python, Ruby and ObjC appscript syntax.”
I was took that to mean, “Use this to learn how you get your apps to listen to Python as though it were AppleScript.” If I’m understanding you correctly, it doesn’t actually mean that at all. It is just a reference for learning how to control Mac apps given the fact that really the only other documentation about controlling Mac apps is about how to do it with AppleScript.
Okay, if that is right, then I like it a lot better. However, I still think I would opt for an OO approach if I were given the choice.
You would need to abstract away all the COM/AE stuff behind an API of your own devising. That means more development work and you probably won’t get the best of of either API (e.g. when working with multiple objects, COM uses iteration; AE will also do iteration but will be much more efficient if you can condense the task into one or two commands with multi-object queries). Still, if the bulk of your program logic isn’t tied to ID, that may be a more economic solution than maintaining two completely separate codebases.
Correct. Most documentation and sample scripts are written in AppleScript, simply because there are more folks using AS than appscript. ASTranslate lets you execute an AppleScript, intercepts any Apple events it sends, and prints those events in appscript syntax. Very handy if you know how to phrase an application command in AppleScript but aren’t sure how to write the appscript equivalent.
Yeah, there’d be merit in OS X gradually switching to a high-level OO IPC system, simply because it OO is a much more common paradigm, and therefore easier for users to understand. It’d likely be easier for application developers to support too. Apple events’ query-driven approach was necessary on Mac OS 7-9, simply because context switches were heinously expensive and limited to 60 per-second, so a fine-grained messaging system like COM would have crawled. OS X can easily sling tens of thousands of messages between processes without breaking a sweat, however, so the cost-benefit ratio of more complex, coarse-grained AE messages is rather poorer nowadays. The main bottleneck is now in the applications processing the queries rather than sending them.
The problem is inertia: the upfront cost of switching IPC technologies now would be considerable, not only for Apple but for application developers and users too. So until such time as Apple bites the bullet or unless major vendors such as Adobe or Microsoft decide to develop a viable alternative, Apple events are where the action is at, for better or worse.
Very helpful, has. Thanks.
I have been using Apple Script for over 6 years now for writing high end chart workflows. AppleScript has served me well. These workflows include, working with the Finder, Excel, Illustrator and sometimes InDesign. I really love AppleScript because it allows me to harness the power of all of these tools using one language.
While I have a background in Javascript for web publishing, and in other coding, I still prefer to work in Applescript for the chart workflows. The main reason, again, is that it can be used for the entire workflow. The chart automations I write are very demanding. The resulting charts are incorporated into the marketing reports for the financial industry. With AppleScript I have been able to extract the data, analyze data, perform all of the calculations, and to place every element of the chart. I don’t use Illustrator’s charting tool. Instead, I draw the objects in Illustrator. AppleScript has given me the control I need to this.
I have been programming in applescript for 10+ years. What got me started was a co-worker had a 64 page Quartk document that hundreds of lines made with a width of “Hairline” (which means the smallest the output device can do). She needed to change them to 1/4 pt. I wrote a one line applescript to change every line of every page. She ran it and 10 seconds later it was done.
10+ years latter dozens of scripts and some AppleScript Applications (using applescript studio yuk) and Ruby has become my language of choice for automation. I use it for file transfers, image processing (rb-appscript), web services to comunicate with remote databases and FileMaker, creating Hot folders on a server from a dedicated mac. Ruby is much more robust than applescript. Easier to code (more compact, better error handling etc…). Ruby has increased my productivity as an automator by leaps and bounds over applescript.
I still use applescript where it makes sense. Droplets for InDesign, Photoshop and Illutrator users to batch process there files for various workflows. But Ruby is my where my heart is.
Dear All, I really appreciated and I come to know the power of Apple script. thanks to all.
But one think, JavaScript is Platform Independent. But Apple script [MacOs] or VBScript[Windows] are not platform independent.
Yes of-course I agreed, the Java script having some limitation in the Development sector. Because I’m a Sr.Software Engineer in Publishing Industry for past 6+years. I used Java Script Its very easy and compatible one, I deployed so many so many developments using Javascript and deployed in the Production floors.
Yes I agree, Javascript is slow to give the output. but Its running depending on the Object-Class methodology.
Still some RnD is going on, for fully supported JAVA -InDesign Development. now its implemented in InDesign Server Concept. In future JAVA is occupied InDesign Application fully.
Sorry I can write anything wrong in this forum.
Thanks & Regards
T.R.Harihara SudhaN
Hi all, I need an indesign script done pretty urgently. Does anyone know any good professional indesign script writers please, thanks, timc@gustavoltd.com
Hi,
Can you batch process open files from the Scripts Panel? I can write an Applescript with the command “Tell every document” and this works for simple scripts. But I’d like to put all the open documents in a list variable (or something to that effect), then do a repeat loop to get each document’s name in order to use the name for exporting pdfs. The script I have works great outside of ID, but it is extremely slow, and I notice that scripts run extremely fast when called from the Scripts Panel.
Thanks in advance.
@Tim, Greg, others: If you have questions about scripting or scripts or scripters, I suggest leaving them on the forums at:
http://indesignsecrets.com/forum/indesign-add-ons-scripts-scripting-and-plug-ins
(You’ll need to sign up for a free membership in order to post there.)