Adobe InDesign Server Rules

When and Why Adobe InDesign Server Rules

By Published On: November 16, 2021

We at Silicon Publishing have been working in the database publishing and online editing space for over twenty years, since the very birth of desktop Adobe InDesign, and long before the initial release of InDesign Server in 2005. Currently, we build the largest solutions in the world for database publishing and online editing, and we have worked with a broad range of tools for document and image generation.

History

Before Adobe offered anything in the way of server-based page composition, the Silicon Publishing co-founders were producing billions of pages of output a year using ancient tools such as Xyvision, VIPP, and 3B2. When we started Silicon Publishing in 2000, we tried every flavor of composition server in existence: Quark DDS, FusionPro, GMC, PageFlex, Exstream, Scene7, PDF libraries, XSL-FO engines, SVG tools, raster imaging libraries… you name it. We also automated InDesign desktop, which gave us fantastic quality of output, but at the price of ridiculously slow speed. We begged Adobe for an InDesign Server, as we worked with their newly released Altercast, Document Server, and FrameMaker Server, all of which had rough edges of their own.

While we attained scale, (for example generating 10 million long complex documents in a very short period of time with FusionPro), try as we might, we could not attain the quality of output offered by InDesign desktop. Quark DDS was the closest in output quality, but suffered from a lack of openness to automation. Simultaneously, we also watched the Quark user base decline evermore with each fresh release of InDesign. Adobe enjoyed such an incredible competitive advantage over Quark, first in terms of resources, but critically in terms of their monopoly in related software. They owned PostScript, PDF, Photoshop, Illustrator, and Acrobat. Initially, these were fairly siloed products, but around 2000 Adobe had begun making them more interoperable, with a Core Tech department enabling shared code libraries.

The creation of the “Adobe Creative Suite” highlighted the advantages InDesign had over Quark. There is just so much convenience to easily interfacing with the industry-standard formats for raster images (Photoshop), vector art (Illustrator), and output (PDF/PostScript)… even if InDesign had enjoyed less composition quality than Quark, there would still be arguments to choose it. But as of the release of “CS1,” the InDesign product was attaining parity with Quark, and surpassing it in some respects, most notably in its incredible exposure to automation. Bundled pricing was a commercial blow to Quark as well.

The CS2 release in 2005 arguably represented an eclipse of Quark for the desktop product, but even more exciting for us, we finally got the InDesign Server that we’d begged and pleaded for during the previous five years. To our knowledge, Adobe had dreamed up InDesign Server without any knowledge of our input, coming up with this brilliant idea on their own.

The “whys” of InDesign Server then and now are many and easily understood, but they can be distilled to this: industrial-strength compositional prowess coupled with tremendous scalability.  If quality is a primary requirement, and the volume of output is high, then IDS truly becomes the natural and obvious choice.  Factor in increasing levels of document complexity and the need for automated data-driven composition with high output volumes, and the arguments in IDS’s favor become ever more compelling.

But.  Perfection always remains as elusive as ever, and if we had any complaints at all about InDesign Server, they centered around its “server” nature. Actually, we were extremely disappointed in the way that those server features had been engineered, and we didn’t like the fact that it wasn’t licensed in a cloud-friendly way. However, even as far back as 2005 we developed workarounds for these issues, and during the past 16 years the gaps in scalability have been eliminated. The license isn’t ideal, but we’ve gotten really good at vertical scaling.

Why not Open Source, web standards, HTML, or XML?

In 2000, if you had asked me what I thought we would be using for server-based document rendition in the next ten years, I would not have answered with “InDesign Server.” At that time, I was 100% convinced that the mighty W3C would give us standards, which would in turn form the basis of future tools bringing high-quality server-based composition in many flavors, both Open Source and proprietary, and that the best solutions would probably be based on combining them.

In addition to the Adobe tools I was playing with (FrameMaker, Illustrator, Photoshop, InDesign, PDF libraries), at that time I was working intensely with SVG, XSL-FO, and CSS. I believed strongly in standards: I owned the SVG Developers Group, which was central to the SVG community; I followed XSL-FO with avid interest, even working on large-scale FO solutions; I also tech edited SVG Unleashed, and wrote a chapter of the XML Handbook. I wanted so badly for standards to succeed.

Yet I was extremely frustrated by the failure of the standards themselves, and I am frustrated to this day. SVG is a relatively decent standard, but it took many years for tools to catch up to it. And it has this awkward relationship with the other standards, such that text in SVG is not of the quality you would want for real documents. It’s like “text for graphics” – the W3C left real text to CSS and XSL-FO. SVG is a good standard for imaging formats, but documents were out of scope.

W3C Formats

Which leaves CSS and XSL-FO. CSS is a great standard for web pages, but they seem to have left print as an afterthought. I have met the CSS working group, and even the few on that group who claim to love print do not seem to go very deep with it. In any case, CSS started out with a non-print goal, and the requirements for backward compatibility are so stringent that it is unlikely to change on a dime.

XSL-FO was actually supposed to tackle formatting for print documents, but it hasn’t managed to do so. FO presents one way you could model a document, but it doesn’t seem to be an ideal one. When I have programmed FO, the lack of a “state-based” angle like that provided by InDesign, where you can look at the state of pagination at any moment and conditionally do things (“can an ad fit in this whitespace?” or “am I at the bottom of the page?”) makes it nearly impossible to get precise output. XSL-FO has not attained widespread adoption, probably because the document model was not that great. It didn’t help that the dominant Open Source FO project, FOP, did not enjoy a large contributor base — when Arvind would go on a fishing trip, the project would stay still for a week.

Web and print are different paradigms

Web and print are different paradigms

Which brings up a peculiar situation that sends serious shops back to proprietary technologies like InDesign Server. For some reason, graphic-centric and document-centric Open Source projects are invariably understaffed. Maybe these are such specialized niches that there aren’t huge companies willing to throw resources at them? There are many home-run Open Source software projects in other domains: Tomcat, MySQL, WordPress etc. But when it comes to graphics and print documents, there is little or no comparable success. Batik and FOP, the two I hoped for the most, were extremely disappointing in the end.

Of the Open Source possibilities, we see the most promise in those approaches that generate PDF from a web page. However, the challenges with web standards mean that you have to really work to make that initial page anything like the quality of an InDesign document. Even if you succeed, then in rendering to PDF you don’t necessarily have easy control over color profiles, etc., all those things Adobe perfected over the years. We still hope that printing directly from the web becomes more viable, but as of now, it’s nothing close to InDesign Server in quality of output.

Proprietary alternatives to InDesign Server

There are still many non-standards-based approaches, which fall into two categories:

  • Ready-to-use proprietary alternatives such as FusionPro, Quadient, or PageFlex.
  • Low-level libraries, such as PDF Lib, Open Source PDF tools, or the Adobe PDF Library.

Proprietary high-level alternatives such as FusionPro or Quadient were often built a long time ago, and generally do not rival InDesign (or Quark, for that matter) in their quality of text flow, fine-grained control over graphics, interoperability with Adobe technologies, or exposure to automation. Sometimes they are valuable in other dimensions: for example Quadient has a robust data-driven rendition capability, and optimization for efficient print format outputs. But if you look at quality of text flow, you will not find anything remotely like InDesign in terms of quality. So such tools may be good for stamping text on top of an InDesign-created PDF, they are not so great for any significant amount of dynamically-composed content that the tools themselves have to compose.

PDF and graphic libraries, can, theoretically, do almost anything InDesign can. However, do you really want to re-create your own text engine? We have done so, and it is not a task for the squeamish. And Adobe has patents in some of their algorithms, such as paragraph composition and optical kerning. It’s an uphill battle to create a high-end PDF renderer, and there are very few examples of success, none rivaling IDS in output quality. The pure rendition is one challenge: making APIs for managing it, or adding interoperability with PDF job options or native Adobe formats represent additional challenges. And how do you make templates? Perhaps you could start with Adobe InDesign, but then the original format will be at odds with the engine used for any dynamic output.

The “When?”

When would you use InDesign Server to automate document composition? There are two conditions that make it the right tool:

  1. Can you afford it? The cost is not insignificant. $5,000/year for the “limited” license (batch composition on your own network), $13,500/year for the public-facing “premium” license which allows you to use it for web sites. This is the main thing obstacle to smaller-scale use cases.
  2. Do you really need high-end composition quality? There are document types where the quality of print and typography are essential, some where they are nearly meaningless, and document types range across the spectrum between these extremes.

Beyond quality of output, the other benefits may push the equation towards InDesign. Often the ease of template setup (starting from the tool of choice for most designers) saves enough time to justify its cost. Other features, such as the fine-grained control of automation, or the fact that you can get an InDesign document back (for those cases where post-generation editing is desired) can be differentiators. Another consideration is the viability and likely longevity of Adobe and the InDesign product.

The “Why?”

If you need quality and can afford it, InDesign Server is the ideal engine for server-based page composition, primarily for the following reasons:

  • IDS has the highest quality of typographical and graphic output of any layout/imaging software.
  • It has complete control over automated output, surpassing any other tool in existence.
  • It shares a source format (.indd) with the most popular tool for print document authoring.
  • It interoperates perfectly with other Adobe file formats: native Photoshop and Illustrator files, and especially Adobe PDF. It shares the same PDF job options as all Adobe desktop apps for fine-grained control over output to print.
  • It can be run in a truly headless fashion on a server, with multiple parallel instances concurrently.

You can contact Silicon Publishing to learn more about Adobe InDesign Server.

Learn more about our partnership with Adobe.

We are a global web to print and automation partner for Adobe products.