Chapter 13. The DITA-to-InDesign Transformation Framework
The DITA-to-InDesign transformation framework enables the generation of InDesign documents and InCopy articles from DITA maps and topics.
The framework consists of both a library of XSLT transforms for generating InCopy articles and a Java library for reading and writing InDesign interchange (INX) files. Generating InDesign from DITA content almost always requires some degree of customization and may require some Java programming if you need to generate complete InDesign documents.
The DITA-to-InDesign framework is intended to provide a low-cost, easy-to-configure path from DITA content to InDesign for publishing PDF. It has been developed primarily to meet the needs of typical Publishing business processes, such as producing magazines and highly-designed books. It does not and cannot provide 100% automation of print layout except in very narrow cases. Because the process is a one-way process that is not directly connected to InDesign itself it is inherently limited in the amount of layout automation it can provide. But it is free.
Where full automation through InDesign is required the Typefi product provides up to 100% automation for publications where the number of titles that use a particular layout design is large enough to justify the investment in setup. See typefi.com for more information on the Typefi product.
The DITA-to-InDesign framework is not intended and does not attempt to provide round tripping between XML and InDesign.
While it is technically possible to do some round tripping when certain constraints are imposed, the presumption of the DITA-to-InDesign process is that, because the InDesign can be regenerated on demand, the need to make changes in InDesign should generally be minimized. Likewise, the cost and complexity of a round-trip-based system is much greater than the cost of managing last-minute text changes can generally justify. The DITA for Publishers formatting domain vocabulary module does provide markup that could be used to capture formatting details but the DITA-to-InDesign tools do not take advantage of this markup in any way.
In the narrower case of InCopy articles (just the text content), it is possible to implement reliable round tripping between XML and InCopy using relatively simple XSLT transforms. The InCopy and INX/ICML knowledge represented in the DITA-to-InDesign XSLT libraries can be used for this purpose but the project does not provide any examples of doing so.
Finally, the DITA-to-InDesign process does not use InDesign's built-in XML handling facilities in any way. These facilities are too limited to allow a general and fully-functional solution to generating best-possible InDesign documents from XML. Rather, the DITA-to-InDesign framework is predicated on generating complete InDesign or InCopy documents directly, which provides full control over all aspects of the final InDesign document except final layout, which can only be done by InDesign itself.
- Generate just InCopy articles (text content only) that are then manually placed into InDesign documents.
This process is appropriate for highly-designed and variable publications such as magazines where it would be impossible or impractical or just not very helpful to generate the InDesign document as well. This is the simplest use of the DITA-to-InDesign framework as it can involve only the DITA-to-InCopy XSLT transform.
-
Generate InCopy articles and a corresponding InDesign document, based on a template InDesign document, that links in each InCopy article.
This process is appropriate for documents where the page layout and general arrangement of pages and frames does not change from title to title, such as less-highly-designed magazines or books with consistent styles. This process can only provide limited layout automation, essentially limited to the first page or first two pages of each article. More automation is possible through custom InDesign scripting or when the individual articles have limited or invariant scope, such as always being exactly one page.
The output of this process is a initial set of InCopy articles and an InDesign document ready for refinement by a Designer. Because the articles are linked from the InDesign document, they can be updated (regenerated or modified by hand) without disturbing the page layout defined in InDesign. This can allow authors and designers to work in parallel as the content is being developed and completed. The main limitation is that any formatting changes made to InCopy articles by a Designer are unavoidably lost if the article is regenerated.
Note that this process requires using Java to generate the InDesign document, which necessarily requires some custom programming.
Also, experience to date suggests that in many, of not most, cases, it is more efficient for designers to manually place the generated InCopy articles because InDesign can automate the creation of new pages in that case.
- Generate a single InDesign document with all stories included directly (not as separate InCopy articles).
This process is appropriate when the layout is mostly or entirely automated or there is some other reason not to keep the articles separate. This approach generally presumes that the Designer will touch the InDesign document once and then be done with it.
Options (2) and (3) require use of the Java INX support library in order to generate the InDesign document. While INX is nominally an XML format, manipulating it is pretty much beyond what on can do productively with XSLT. The INX support library provides a full abstract data model for manipulating and creating INX documents, allowing you to do anything that doesn't require knowledge of how flowing content is formatted. For example, you can create new spreads, pages, and frames, create or link stories or media files, calculate the relative geometry of frames and so on.
Generating InCopy and InDesign effectively requires some understanding of how InDesign works and general techniques for optimizing your InDesign templates and paragraph and character styles to enable maximum automation. Many of these optimizations are not things that Designers normally do so you will likely need to work closely with your Designer to help them understand how to add the necessary enhancements to your InDesign templates.
This section uses the term "Designer" to mean anyone preforming the task of creating or modifying InDesign documents, and in particular, the design of the visual aspects of documents such as page design, typographic details, and so on, as well as doing the manual work required to create final-form printed documents using InDesign. One of the design goals of the DITA-to-InDesign tools is to automate the manual aspects of this job as much as possible, allowing Designers to focus on the creative design aspects of documents, rather than the non-creative tasks of simply getting content into InDesign.
DITA-to-InDesign does not change the roll of Designers as Designers, that is, as the implementors of specific visions for the visual presentation of information because it leaves the design task in the design tools domain rather than moving it into the data processing domain as in the case of batch formatting systems such as XSL-FO and similar non-interactive composition software.