A Print Solution to Complement Your CMS Workflow: Part 2

by Lisa Bos

May 2004

This is the second and final installment in our series on the various options available today when choosing a print solution to complement your CMS. In the first part, we looked at the different categories of print composition systems and identified the software products most often used by publishers and how they are used in traditional print-driven workflow scenarios. Now we'll take a look at single-source workflows and how the available software supports them.

Integration with Single-Source Content Management Systems and Workflows Using XML

Single-source workflows are those in which content is created once in a neutral format (like XML) and then published to many output formats.

High-End Composition Systems and Single-Source

The high-end solutions and FrameMaker (server edition) are specifically designed to support single-source systems. Integration between CMS's and the composition system is typically file-based. The diagram above is an example of how this integration might be implemented.

Because the high-end products and FrameMaker are designed for single-source workflows and automation, by necessity they have powerful methods for ingesting XML without human intervention. The exact means by which XML is ingested varies, but each of the products identified in this article does the job well once configured.

These product vendors understand the relationship between their products and content management systems well. It is not surprising that one of them (XyEnterprise) offers its own CMS and the others have informal relationships with CMS vendors. It is also interesting to see that one of the vendors (Arbortext) includes strong capabilities for transformations to output formats other than print. In fact, what was formerly a stand-alone print composition product is now packaged together with other capabilities such as transformation to various digital formats to create a much more comprehensive publishing solution.

Desktop Publishing Products and Single-Source

Desktop products like InDesign and XPress are not designed for single-source workflows, and it shows in their XML capabilities (or lack thereof). Both InDesign and XPress do have some native XML capabilities, but not enough to enable fully automated publishing. Third-party products are worth investigating if you want to work this way.

This is not to say that you can't publish with InDesign or XPress if you author your content as XML. However, it does mean that you cannot expect a fully automated process for importing XML into your pages. But, that's ok. If you've decided one of these products is right for you, that's probably because you need to adjust pages and use the advanced page design features these products offer, and your goal isn't complete automation so much as making the job of importing XML reasonably efficient. This is very achievable.

In reality, most publishers who want to use InDesign or XPress do not choose a true single-source workflow. This is because for many of them it is important that authors or at least editors be given an accurate representation of what their pages will look like prior to saying that content has been completed. This is at the least very inefficient with these products because completely automated composition from XML is not possible in them. Publishers who truly believe they must use InDesign or XPress but who still want some of the benefits of single-sourcing might consider using a production management system or the Documentum implementation mentioned in part 1 of this series.

When considering the role of desktop tools in single-source environments, it is instructional to observe that Adobe, which knows something about publishing, has chosen to maintain separate products for batch publishing (FrameMaker) and for highly-designed desktop publishing (InDesign). This tells us that Adobe sees a continuing segmentation between the two categories of composition tools we've identified. As a result, Adobe doesn't position InDesign as a component of automated, single-source environments. (Although Adobe does tout the option to export XML from one InDesign document and then re-import it into another template to achieve a different layout of the same content—and calls this single-sourcing.)

Past and Future Technologies

Many publishers, especially academic publishers of mathematical and scientific papers, have been using a technology called TeX for more than 25 years. (According to the creator of TeX, Don Knuth, TeX rhymes with "blecchhh.") TeX is a typesetting language that was supported by many free software tools long before the idea of open source software became widely known. Because it's affordable, powerful, and able to render mathematical equations, TeX became popular among authors of information as well as with professional publishers and compositors. TeX is still widely used, and probably will be until MathML (the XML language for mathematics) is widely supported by editing tools (including free ones) and composition engines. The 3B2 product still uses TeX for mathematics. And, in recent years, publishers and vendors have experimented with the conversion of XML to and from TeX, with much success. Depending on the nature of your content and publishing needs, TeX could be worth a look as an automated print solution for your single-source environment.

You should also be aware of a more recent technology, XSL:FO. Like TeX, XSL:FO is a page typesetting language, but in this case one that leverages the XML syntax. (XSL:FO is part of the W3C's XSL family of recommendations.) The objective of XSL:FO is to enable automated page composition from XML documents. There are a number of commercial products and at least one open source application that enables the creation of PDF files from XML using an XSL:FO script. To date, most publishers who have experimented with these tools have found them wanting in some way. In fact, XSL:FO itself is missing features important to some publishers.

However, the long-term trend for XSL:FO (or "FO" as it is often called) looks good, and in the short term it is already in use by professional publishers for some more narrow applications. Two of these are on-demand creation of PDFs for individual documents or small custom publications, and the creation of editorial page proofs where exact pagination doesn't matter. XSL:FO is also being taken seriously by the high-end composition vendors. In fact, Advent has released 3B2-FO, which enables you to use your XSL:FO scripts with 3B2. We have even encountered an implementation of XSL:FO that uses TeX to render pages behind the scenes.

Choosing a Solution

The bottom line is that choosing your CMS workflow is tightly bound up with your print composition requirements. Before you make those final workflow choices, consider the following:

If you currently vary the layout and formatting of your printed pages, ask yourself whether you do so because it's necessary to compete for your audience, or simply out of habit. Publishing staff sometimes resist format- and layout-neutral content development because it is unfamiliar or threatening to their current roles, not because it isn't possible or appropriate.
Is it possible that moving to automated composition will help you accomplish other goals, such as refocusing staff on the content itself and/or on your electronic products?
Don't underestimate the complexities associated with some types of publishing. Looseleaf is the best example of complex publishing that can drive your entire workflow. It's as easy for technical staff or management to oversimplify print composition complexities as it is for editorial and production staff to overstate them.
It might be appropriate for you to use different print tools for your different publication types. Many publishers have both variable format periodicals (newsletters, magazines) as well as highly consistent and high-volume publications (journals, reference books), and trying to get one solution to fit all might be more work than supporting two systems.

Outsourcing

Finally, if you're about to invest in print software along with a CMS, consider outsourcing print composition instead. This is especially appropriate if electronic consumption of your information is going to outpace print usage (and revenue) before you see the return on your investment. You might also consider outsourcing for the short term to test out a print tool or workflow before completing your internal changes. Permanent- or short-term outsourcing can be particularly appealing if you are moving to a high-end product for the first time. It avoids the learning curve, the cost, and the complexity (risk) associated with the transition.