Making FrameMaker work for you

Many jobs are tedious, involving a repetitive sequence of commands that must be executed on a large number of almost identical elements in a document. And because they are tedious and feel like a waste of time on the part of the author, attention may decrease, and errors may go unnoticed. This, apart from the increase in efficiency, is a good enough reason in itself to think about automating such tasks. Whenever there is a defined pattern in the items to be identified and the tasks to be performed, scripting is the right choice. And with the ExtendScript Toolkit being shipped with FrameMaker 10 or higher, you do not need to purchase external tools or learn a complicated programming language.

Adobe’s ExtendScript Toolkit was first introduced in Adobe’s Creative Suite and could be used to automate repetitive tasks in Photoshop Illustrator and other Adobe programs. As of FrameMaker 10, the same ExtendScript Toolkit is now available to handle objects in technical documents. The scripting language is based on JavaScript extended with objects and methods specific to each of the installed Adobe products that support scripting. In fact, the ESTK gives access to the API of the Adobe program without having to know the C++ or another advanced programming language.

Scripting in the ESTK is fairly easy, with the editor helping you out through auto-completion of objects, properties, and methods wherever this is appropriate and possible. Of course, you will need to have the FrameMaker Scripting Guide available as well, to look up all those elements that can be accessed in your scripts. And, to be perfectly honest, I did download the FDK documentation for reference to some tricky stuff that the Scripting Guide did not provide enough detail about. Translating the info from the C++ API to the JavaScript equivalent proved not to be too complicated.

Everything in ExtendScripting starts from the top level, whether you are looking at FrameMaker-related objects (which are part of the app top-level object) or at document elements (which are part of the ActiveDoc or ActiveBook top-level object). Drilling down the hierarchical model to the object you want to address (such as a table cell or the filename of a referenced image file in an anchored frame) is a matter of reading the specifications in the Scripting Guide, writing simple test scripts and using the Data Browser.

One absolute requirement when starting scripting is to register for the Adobe User Forums and making a bookmark that points directly to the FrameMaker Scripting forum. Any question you may have is read by dozens of scripting specialists around the world, who are more than willing to help you out when you get stuck. And if all else fails, there is always the option to ask one of these professional scripters to write the script for you for a nominal fee.

Of course, this blog post cannot hope to be an ExtendScript tutorial, although I am trying to post helpful tips and tricks while I go along. In this post, I just want to point out that there is a good reason to try this free out-of-the-box option for yourself and see what it can bring regarding more efficiency and less tedious and error-prone work. After I got started in the fall of 2011, I have successfully created a number of custom content management systems for my clients, all of them written exclusively in ExtendScript. If you read my bio below, you will see that I did not study Computer Science and had no prior programming skills. So I figure if I can do this you should all be able to do it, too.

One of the extras in learning to use ExtendScript with FrameMaker is that the exact same toolkit and language also gives you scripting access to a growing number of other Adobe applications. I am already looking at options to create scripts that span multiple applications and streamline the inter-application communication of objects and files. That may be taken as a warning: once you get started on this, it might turn out to be so much fun that stopping may be hard.