XML is a beautiful thing…primarily for geeky people who are passionate about topics like workflow automation and industrial strength publishing solutions. Being able to describe document geometry and document content in a non-binary file format that can be edited and manipulated by databases, scripts, and other processes enables a vast universe of vertical market solutions that can save publishers a lot of time and money, as well as offer opportunities for new types of publishing products.
For the last few versions, InDesign has enabled you to export page objects or entire documents in an XML file format called .INX. It was designed primarily for backward compatibility, and it enables you to take documents from, for example, InDesign CS3 to InDesign CS2. What it was not designed to be was human readable…or easy to deconstruct, edit, and put back together again. Nevertheless, many third pary developers expended substantial effort to do just that simply because of the workflow opportunities afforded by a text only XML file format that would enable applications other than InDesign to create and/or edit document files.
What third party solution providers wanted to be able to do with .INX are things like:
- Programmatically create .INX outside InDesign, i.e., create InDesign document files using a database or some other application
- Edit or transform document
- Programmatically replace old with new content
- Extract and recombine document subcomponents
- Include and preserve their own proprietary data in the .INX structure
- Validate the .INX document structure
- Pre-flight the .INX code
- Execute processes on INX using industry standard tools like XSLT, XQuery, E4X, RelaxNG validators, and converters
- Build rich internet applications that serve as front ends to a publishing system that uses InDesign Server as the layout engine.
Because INX was not designed to be used in these ways, and because Adobe did not officially support it, building workflows around .INX was challenging at best. Many dedicated developers, however, did just that, doing their best to work around the format’s obstacles and limitations.
With the release of InDesign CS4, Adobe has delivered a new document XML file format that is actually designed to be a developer tool. IDML is the best thing since sliced bread for third party solution developers who have been wrestling with the inadequacies of the INX for building web to print and other workflow automation solutions. It’s designed to be everything that .INX was not when it comes to supporting third party development.
The primary design goals of IDML are:
- Completeness: Any object, attribute, or preference can be represented in IDML. Complete "round trip" compatibility is expected of IDML files.
- Readability: The IDML format is human-readable, IDML is designed to be read and written by virtually any program or tool capable of reading and writing XML.
- Robustness: Developers have more visibility to errors and increased flexibility in handling them as well.
- Backward compatibility: A user will be able to take an IDML file generated for version X and open it in version X-1
- Performance: IDML aims to maintain or exceed the performance of INX.
We’ve designed IDML to make it a key part of automated workflows. Using IDML, you can:
- Programmatically generate or modify IDML documents
- Re-use parts of IDML documents in other documents
- Break a document into components
- Transform document elements using XSLT
- Find data in InDesign documents using XPath.
Here’s a small sample of IDML code to illustrate the human readability, part of the description of a text frame:
<ItemGeometry NumPath="1" GeometricBounds="31 31 571 751" TransformationMatrix="1 0 0 1 5 -391">
<GeometryPath NumPoint="4" IsOpen="false">
<PathPoint AnchorPoint="31 31" LeftDirectionPoint="31 31" RightDirectionPoint="31 31"/>
<PathPoint AnchorPoint="31 751" LeftDirectionPoint="31 751" RightDirectionPoint="31 751"/>
<PathPoint AnchorPoint="571 751" LeftDirectionPoint="571 751" RightDirectionPoint="571 751"/>
<PathPoint AnchorPoint="571 31" LeftDirectionPoint="571 31" RightDirectionPoint="571 31"/>
SUPPORT FOR THIRD PARTY DATA
IDML supports the inclusion of new scripting objects and properties added by 3rd part InDesign plug-ins. This means that third parties can embed their own proprietary data, any features added by plug-ins that support InDesign scripting can be included in the IDML package.
IDML EXPORT PACKAGE
When you export a document as IDML, InDesign creates a Zip archive containing multiple XML files.
The InDesign document is split into separate files representing different aspects of an InDesign document so that you can more easily identify and perform operations on the objects and properties you need. Document resources, spreads (page geometries), and stories are stored in different XML files within the zipped package.
So, what becomes of INX and all its variants in past InDesign and InCopy workflows? First, here’s a list of XML formats supported by InDesign and InCopy CS4:
- IDML – InDesign Markup Language
- ICML – InCopy stories will be InCopy Markup Language
- INCD – old style InCopy story format used from InCopy 2.0 through CS2
- INCX – CS4 will have inport/export support for INCX
- INX traditional – the old style format that the INX clients have used from CS through CS3
INX will continue to be used for backward compatibility for InDesign versions prior to InDesign CS4.
IDML will be used for backward compatibility between InDesign CS4 and future versions.
Note: CS4 has no export support for INCD; however, we will continue to support INCD import.
The advent of IDML as a developer technology is a major development in the history of InDesign. We expect IDML to be leveraged extensively by third parties to deliver innovative and powerful publishing solutions to the market.
If you’re a developer interested in learning more about IDML, you can do that do that through our developer partner program.