Publishers, worldwide, have accepted InDesign over the years as a worthy tool in their arsenal. One of the main reasons for InDesign’s acceptance is its design capabilities and scope for automation in a world that demands extremely short TATs and cost efficiencies.

Automation in InDesign can either be done from a high-level approach with supported scripts or diving deep into the InDesign SDK and develop a native plug-in. Both approaches have their advantages and limitations.

Let’s look at the easier option of scripting first. InDesign offers great support for scripting. Creating and running a script in InDesign is relatively inexpensive, easier for the programmers, and has a short turnaround time to develop. One can say that almost all of InDesign’s functionalities can be evoked through the ExtendScript Toolkit. For these reasons, a faction of developers go the script road rather than develop a plug-in. Scripts can be used for simple tasks like how a macro functions and also for complex tasks that improve performance.

InDesign evolved and with the introduction of the Script UI. Scripts could be run in the background and could be run in interfaces involving dynamic input. With Script UI, scripting embraced greater functionality and could dream of scaling up to plug-ins’ capabilities. However, scripting can be used only to automate existing functionalities and plug-ins allow developers to create new functionalities and create value in situations where high performance is vital.

For this reason, a segment of developers swear by plug-ins and take the time and pain in deep level coding that allows them access to InDesign’s core architecture. While InDesign’s SDK is extensive and requires a deep understanding of C++, standard libraries, and software patterns the benefits outweigh the effort involved. Plug-ins can create newer functionalities and offer seamless integration in high-critical areas.

The question then arises, “What should a publisher and their supplier choose to leverage their automation processes?” There is no universal solution. The journey continues and each software engineering team has to create their own solution to meet their custom needs. To script or develop a plug-in for extending functionalities — that’s for the customer’s needs to decide.