Designers often reuse information: a mission statement may appear in a brochure and an annual report, for example, and product descriptions can be used in paper catalogs and on company Web sites. If you could extract these elements as XML, which separates the information’s content from its structure, repurposing would be a lot easier. Both InDesign 2 and QuarkXPress 5 have XML capabilities, although Adobe says that InDesign’s XML features are still in beta form.
Neither product is for the complete XML novice; both require that you know at least the concepts and vocabulary of XML — tags, elements, and attributes — and XPress requires that you know more. (For an introduction to XML, see ” Inside XML,” October 2000.)
Both XPress and InDesign rely on plug-ins (avenue.quark and XMedia UI, respectively) to export XML files from native XPress and InDesign documents and to import XML files into the applications.
Both plug-ins let you extract formatted text from an XPress or InDesign document and wrap XML tags around that content to make an XML file. Essentially, you open a formatted layout that contains text and graphics, drag and drop to associate XML tags with named styled components (paragraph and character styles), and then tell the software to create an XML file.
In XPress, you drop the text components onto a tree diagram of your XML file, according to tagging rules you have previously set (see
the top screenshot). In InDesign, you drop tag names onto styled areas (text or graphics frames) or select a frame and click on a tag name (see the bottom screenshot).
Both products can tag text boxes one at a time or associate named styles with tag names to tag an entire document at once. XPress does not export pointers to graphics files; InDesign does.
Tag, You’re It In InDesign, you can create tag names on-the-fly, typing them into a form or importing a set of tags from an existing XML file or InDesign document. The tag names are displayed in alphabetical order. In contrast, avenue.quark requires predefined XML models — called Document Type Definitions (DTDs). Each model contains a set of tags and tagging rules.
InDesign’s ad-hoc tags could be an advantage when you’re taking care of those annoying late-night production crises, but there is potential for downstream process problems, since XML documents usually have rules that are meant to be followed. InDesign’s approach falls short in other areas, too. Alphabetical lists are fine for 20 tags, but many real tag sets run into the hundreds. And this tag list doesn’t help you figure out which tags to apply where. Furthermore, InDesign outputs only those tags you have explicitly mapped to styles. That’s a drawback because the program won’t import “wrapper” tags, such as a list element that surrounds sev-eral list items.
XPress’s reliance on a DTD is logical because customers who need you to create XML output can likely provide you with a DTD or an XML schema, which can become a DTD. This means that tags come in com-plete sets and display in a structured tree view that shows the tagging rules. The tree view shows all the tags there can be and where they are used — for example that a <figure> contains a <title>, a <graphic>, and a <caption>. XPress can output wrapper tags (such as <body>) that you do not have to choose or key in. Containment and wrappers are one of the key differences between XML and flat page-layout structures.
Table Setting In both applications, XML tables are more trouble and more work than text and headings. InDesign lets you import a simple table (no vertical or horizontal spans), but before import, you must set up a table layout of exactly the right size and shape, which is hardly convenient. You can also export simple XML tables. XPress doesn’t recognize tabs or separate styles to identify headings or rows of
a table, so you have to deal with a table one cell at a time. In both programs, you’re better off treating complex tables as a graphic or manually cutting and pasting in each cell.
The Bottom Line InDesign’s XML features are not as complicated as XPress’s, and they have simpler and better documentation. Because you can perform many tasks in more than one way, you can choose the way that you find to be most intuitive. The ability to export a document as XML by mapping its named styles directly to tags of the same name, thereby producing some XML, is valuable.
XPress’s avenue.quark XML plug-in is more powerful, at least potentially. But it’s also more complex. The plug-in not only allows for more control but also demands it. You should not approach avenue.quark without both XML and avenue-specific training.
Both products can be frustrating. Unexpected key strokes in InDesign can crash the program. Although avenue.quark is much better than it was a year ago, its user interface is sometimes awkward — for example, when you’re manipulating within placeholders. And when things go wrong in avenue.quark, it’s often impossible to recover gracefully — because the Undo command frequently doesn’t work as it should. If you’re serious about extracting XML from XPress, you’d be better off with conversion-mapping software, available from many sources including Apropos, Easy Press, Noonetime, North Atlantic Publishing Systems, and PCI.
Back to Quark XPress versus InDesign.