There's a New Scripting Tool in the Box

The introduction ExtendScript support in FrameMaker 10 offers new possibilities for augmenting the built-in capabilities of the Adobe FrameMaker product. FrameMaker has long been extensible but prior to release 10, extending FrameMaker meant mastering the intricacies of the Frame Developer Kit (FDK).

The FDK extends the capabilities of FrameMaker by allowing for the creation of C language plug-ins. Such plug-ins have great power as they can be used to mimic just about any action a user might take, thus offering vast automation potential. FDK plug-in also can be integrated into the FrameMaker menu structure making FDK commands operate as if they were part of the out-of-the box product.

Developing such plug-ins requires knowledge of the C programming language. The development process entails writing, compiling, and debugging code using Microsoft Visual C development tools. The FDK developer needs to master a voluminous set of objects, properties, functions along with complex data structures. As C has no built-in garbage collection, FDK programmers also have to deal with memory management, a task which when bungled is all but sure to lead to unpredictable and catastrophic crashes.

The challenges of FDK plug-in development meant that only a small fraction of Frame users attempted plug-in creation. Plug-ins became something large corporations commissioned and less well-heeled users purchased from third-party developers.

The addition of ExtendScript scripting to FrameMaker 10 not only makes extending FrameMaker potentially easier, but it also moves FrameMaker further along the road to full-fledged integration with the larger set of Adobe products. (Adobe acquired FrameMaker in 1995.) A major step came in release 9 with a major UI redesign that made FrameMaker look and feel more like Adobe products such as Photoshop and InDesign. I cannot help but believe that this bodes well for FrameMaker's future and for its ability to "play well" other Adobe products.

My focus here, however, is not on interoperability but on the promise implicit in ExtendScript support that FrameMaker users now will be able to construct scripts that have the power of FDK plug-ins without the need for heavy-duty programming skills.

I would be remiss not to mention that the third-party created FrameScript has long offered an alternative to FDK plug-in development. (See http://www.framescript.com for more information.) I will not, however, be discussing FrameScript. My focus is strictly on taking a very close look at Adobe's ExtendScript implementation of FDK functionality.

I have been an FDK programmer for many years. I started learning the FDK, even before its public release, as I prepared the first FrameMaker training class for Frame Technology. Having taught FDK developer classes too many times to count, in many states and several countries, and having  developed numerous FrameMaker plug-ins for corporate users, the F_Api prefix that starts of FDK functions is hard-wired in my brain.  Thus, I cannot help but view the ExtendScript toolkit from the perspective of an FDK programmer.

But while, I may frequently reference FDK code, my intention is that anyone who is new to the ExtendScript FrameMaker toolkit will find this blog helpful. I plan to look at common-place tasks in FrameMaker customization and show how they can be scripted using ExtendScript. I will provide code examples and commentary. When I digress into areas of interest only to FDK programmers, I will provide ample warning. I will assume that you know end-user FrameMaker and that you have some scripting experience but not that you are familiar with ExtendScript or even JavaScript. I will be posting irregularly, as I come up with useful examples and information. So, please stay tuned.