A Brief History of Adobe InDesign Control in a Simple Workspace
A brief history
InDesign was born in 1999. Just like J2S! The industry knew we had developed extensions for QuarkXPress, the leading DTP1 software. Naturally, our network requested that we automate the operation of Adobe’s new solution.
That happened in 2005 before InDesign Server2 was released. InDesign Server provided an official method of controlling InDesign from the outside. It is worth noting that Adobe’s End User License Agreement prohibited using the desktop version in an automated context.
Since no solution was available, we developed our tools.
The first plug-ins
Adobe InDesign was initially designed with a set of plug-ins in mind. It included an SDK that allowed for the development of additional plug-ins, which played a vital role in the software’s functionality.
One of the resulting plug-ins was J2S NetToolbox, which expanded the capabilities of Adobe InDesign to connect with external networks. It enabled requests to be made in XML format using XML-RPC, allowing for basic operations such as opening, closing, saving, and exporting documents.
Subsequently, J2S LayoutToolbox was introduced as an extension of J2S NetToolbox. This plug-in provided an essential new feature: the ability to perform automatic layout3.
J2S Dispatcher, constant performance and service continuity
Working in a production context, we quickly realized that we needed a driver to act as a link between the sender of the request and Adobe InDesign (desktop version at the time). The result was J2S Dispatcher. Our decision was validated when the InDesign Server launched. For a server requiring numerous instances, J2S Dispatcher was the obvious choice.!
J2S Dispatcher has two goals:
- Ensure continuity of service;
- Maintain a constant level of performance.
The primary goals of J2S Dispatcher are to ensure uninterrupted service and maintain consistent performance. J2S Dispatcher continually monitors the instances it manages to ensure they are functioning properly, are efficiently executed, do not use excessive memory, and have adequate capacity. If necessary, instances are launched or restarted to maintain an optimal state.
Additionally, J2S Dispatcher allocates requests to different instances based on the specific InDesign versions and their availability. When all instances are busy, requests are queued until an instance becomes available.
The future
InDesign versions are released in a short space of time. We keep a constant watch to keep up with this pace while guaranteeing the best possible continuity of service 4. (Cautiously, since J2S Dispatcher can serve different versions of Adobe InDesign, the most recent versions are gradually put into service).
At the same time, we’re exploring future architectures that will offer even more organizational flexibility and resilience5. These projects take into consideration the rapid evolution of Cloud architectures. For instance, these new architectures will continue to support local machines and also allow requests to be directed to other data centers.
IT never stops.
As you can see, we’re experts in this field: no matter the situation, we can help. Contact us : We’d be delighted to hear from you.
Jean-Yves Jourdain, Cofounder of J2S
Older users will remember the Adobe PageMaker / Apple LaserWriter pairing that launched DTP. ↩︎
Read this article which explains how Adobe InDesign Server works “ Have you ever heard about Adobe InDesign server? ” ↩︎
Speaking of layout automation, be sure to check out this article “Automation of the layout and “responsive print” what does it mean?” ↩︎
For each new version of InDesign, there’s a new SDK, so we have to review all our plug-ins. ↩︎
About architecture, reread this article “Simple Workspace hosting, how does it work?” . ↩︎