In just a few years, InDesign Server has managed to completely dominate the market of web-to-print applications. Many vendors (including ourselves) use it as the main engine for variable database publishing.And that's not surprising, because there are a lot of advantages.
Easy template building
If a database publishing application is used for the creation of a catalog, the configuration of the templates might not matter very much. The time spend there can hardly be compared to the time spent in manual creation. But when the templates are used to populate a web to print application, intensive configuration processes become prohibitive. Often these web to print applications contain a large amount of templates, and the time spent configuring them can't be too long.
By starting from existing InDesign documents, the web to print application can be kept up to date much more easily. Not only are there more people available to help in the template building process, but they also need less training. Especially simple templates are a piece of cake.
But still, a good database publishing system will need additions on top of InDesign Server. Not everything is possible in InDesign Server by default. Copy-fitting, diagonal strike throughs, intelligent placement of images, etc. are typically actions executed manually by the DTP personnel. In a web to print application, the tools need to exist to configure these settings on top of a template.
Output of InDesign Packages
For database publishing more than for anything else, most of the cost often lies in the final finishing. Creating a brochure that is 90% complete is often enourmously more easy to accomplish than creating a database publishing workflow that is 100% automatic. Surely any web to print application needs to be able to handle a lot of exceptions, but in some cases it is also possible to ignore the exceptions. Let InDesign Server create an InDesign package as output of the database publishing workflow, and finalize that (in a minimum of time) in the studio.
And in some cases, database publishing can only go 20% of the way. But even this can significantly reduce the production cost. A web to print interface can be created in which end users (marketing, product management, ...) simply prepare the job for the studio. Rather than creating a complete design, the output of their database publishing activities is an InDesign package with the raw data of the job. Some elements of this data may already be formatted (price pannels, promotions, ...) but the basic idea here is that DTP saves time on data gathering, not on designing.
All graphical features supported
While some web to print applications don't need all complex graphical features, it certainly doesn't hurt to have access to good hyphenation libraries. By using InDesign Server, this and many more becomes available in an automatic database publishing workflow. Copyfitting of a simple name on a business card is one thing. An easy thing. But copyfitting of an entire brochure, with regard for paragraph styles of titles, hyphenation, leading and trailing white, and so on. That's a completely different thing. A hard thing. But InDesign Server brings this power to a web to print application without much fuss.
Just using the standard features of InDesign, a lot can be accomplished without much programming by the database publishing system on top of it. Layers, word breaks, language dictionaries, text wrap, and many more features can be used standard.
Disadvantages
But of course the use of InDesign Server comes with some disadvantages as well. First of all, it still costs quite a bundle. Prices have dropped over the past few years as demand grew, but InDesign Server still counts for a fairly large percentage of a database publishing budget. And, being based on a desktop software, it does not always have the performance of web to print templating systems specifically built for automation.
And let's not forget stability. While InDesign Server comes with a great SDK, real live situations often can't be documented by Adobe in advance. So small issues will arise with actual database publishing. Almost always a workaround can be implemented for these issues, but the only way to find out about them is to experience them yourself. Luckily, it is completely possible to build a stable system over time in this way.
Conclusion
We're glad that we have been automating InDesign since the 1.5 release. It gave us the experience needed for a complete implementation of InDesign Server in our database publishing solutions. But we're also glad that we took the time and invested in a second (PDF based) templating system.