Scenario: You work for a publisher that specializes in printing maps and atlases. The production department sent over the layout for the latest project along with the XML file and support files to supply the content.

With the frame edges turned on, you should notice three anchored frames in the layout. One frame holds the flag, another the map, and the third is just for show. We discuss the strategy of using the third anchored frame in the sidebar “Anchored Object Strategy” later in the chapter. For now, let’s concentrate on learning how to combine text and graphics in your XML workflow.

Whenever you approach a project built by someone else, get into the habit of dissecting the structure to understand the order and placement of the tagged placeholders, and identify any elements to be cloned before proceeding to the next step (Figure 6.1).

Figure 6.1. Use the Structure pane and the Selection and Text tools to match the XML elements with their placeholders in Layout view.

Ready for some more magic?

If you’ve been paying attention to how often we’ve mentioned that XML is a plain-text language, getting pictures to appear automatically in a structured layout may seem downright miraculous. But it’s really not that spectacular if you know anything about Web design (Figure 6.2).

Figure 6.2. Although HTML is a plain-text language, it has no problems supporting graphics. The HTML code simply tells the browser which graphic to load and where to find it.

Recall that, like XML, HTML is also a plain-text language, and it certainly doesn’t seem to have any problems dealing with graphics. Why? Because HTML doesn’t create the graphics; it simply references them in the code. In other words, it tells the browser where the graphics are stored on the Internet. For example, to insert a graphic called logo.jpg on a Web page, you insert the following code in the HTML:

<img src="logo.jpg">

Written this way, the reference indicates that the image file logo.jpg is saved in the same server and folder as the HTML file that is referencing it. If the graphic is stored elsewhere, you also have to include some path information indicating on what server and in which folder it can be found.

Paths come in two varieties: absolute or relative. Absolute paths leave nothing to chance, including the exact location of the graphic down to the server name, as in the following:

<img src="http://www.cookingwithxml.com/images/logo.jpg">

Relative paths are more open and flexible. They simply indicate where an image can be located in relation to the current Web page or document, such as:

<img src="images/logo.jpg">

The preceding reference tells the browser that logo.jpg is located in the subfolder images.

Absolute and relative references both have advantages and disadvantages. For example, using an absolute path tells the browser exactly where to find the graphic. That’s great if the graphic file is located in static location and you have to move the Web page files around, because the browser will always find the graphic—it’s in a fixed location. But if the graphic is moved, the path reference is suddenly wrong.

Relative references are great if the graphic is stored in the same location as the Web page or within a subfolder. Because the reference is relative, the entire folder (containing the Web page and the image) can be copied to a new location, or server, without breaking the path.

But how does this all relate to graphics in an XML workflow? XML uses a similar method to reference graphics, which can also be written as either absolute or relative. To re-create the same graphic reference cited earlier in XML, you would type the following:

Absolute: <image href="file:http://www.cookingwithxml.com/images/logo.jpg" />

Relative: <image href="file://images/logo.jpg" />

Let’s see how the graphics are referenced within the atlas XML file.

It should be pretty obvious that this piece of code references the name and location of the U.S. flag graphic used in the atlas. Because the reference doesn’t spell out the hard drive or Web server name, we can also deduce that this is a relative reference. Therefore, the file us-flag.pdf should be located in a subfolder called images. Let’s check it out.

Within the images subfolder you should find all the graphics used in the atlas, including us-flag.pdf. InDesign is able to find and import these graphics because they are stored in a subfolder relative to the location where the XML file is found. As with all relative references, you can move the XML file to any computer or hard drive you please, just as long as you also move the images subfolder to the same location.

So, the important thing to understand is that the XML file doesn’t create the graphic; it simply identifies which graphic to import and where it can be found.

With the experience of putting together the cookbook in Chapter 5 under your belt, building the structured layout for the atlas should be a simple matter. As always we start with the basic document setup:

You should notice that the icon clearly indicates that the Flag element is a graphic (see Table 2.1 in Chapter 2). In place of the data text snippet you’ll see the icon for an XML attribute and, beside it, the attribute text snippet.

Observe the attribute’s Name and Value. The name, HREF, stands for hypertext reference and is used in HTML to display a graphic on a Web page. The Value attribute stores the path describing the exact location of the graphic file. Whenever a graphic is placed in InDesign and tagged with an XML element, the program constructs this attribute automatically using an absolute reference (see Lesson 6-2).

Stop a moment to enjoy the miracle you just witnessed. The magic might not seem that impressive unless you remember that the Structure pane itself contains no graphics, just path statements like the one we observed in step 6 and earlier in Lesson 6-2. Yet that’s all InDesign needs to track down the proper graphic and place it in your layout. Fantastic!

In the Structure pane you should see ten total entries for the atlas, but to build the structure you only need the one element already placed in the layout. In fact, as we describe in Chapter 5, the remaining elements must be deleted or they will wreck the structure. As long as you delete the superfluous elements before importing the XML, it doesn’t matter when you do it. So, now is as good as any other time.

Now you’re ready to start building the formatted structure.

The graphics placed automatically by flowing XML into a document appear in the text as inline anchored objects. This default behavior comes in handy in many XML workflows. In this particular layout we want the graphics to appear in specific locations on the page. In this lesson we set up the proper relationship for the anchored graphics.

Before we begin, it’s important to observe some key aspects of our current structure.

Note how each is on a line of its own and separated by the continent element. No matter what you do in the final structure, it’s vital that these elements (as well as all the others) remain in the order currently displayed so they match the structure of the imported XML.

Moving the two anchored graphics to the top of the page has left some unwanted gaps in the text. Getting rid of the extra space won’t hurt the structure—if you’re careful (Figure 6.8).

Figure 6.8. Here the map graphic has been floated from its original position in its own paragraph, leaving an undesirable hole in the text. The dashed line indicates the location of the frame’s anchor marker.

Now it’s time to insert the background frame as an anchored object.

One potential problem that can disrupt XML workflows is that anchored objects can shift from their desired locations during cloning when their positions are manually formatted. To prevent object shifting altogether, formalize the design using Object styles.

To create Object styles do this:

If you have never used it (or changed the settings) before, all checkboxes in the New Object Style dialog are checked by default, except for the Paragraph styles settings. By having the formatted frame selected, all the specifications you just applied will be automatically captured when the new Object style is created. The settings we are most interested in are Fill, Stroke, and Anchored Object Options, but make sure all the boxes remain checked to maintain consistent formatting. For anchored graphic objects, the Paragraph styles settings are irrelevant, but come in handy for anchored text frames like the one used in the cookbook in Chapter 5.

All objects are now styled properly.

In Chapter 5, we added the words Ingredients and Directions to the structured layout so they could introduce the appropriate parts of each recipe. These words were then cloned automatically when the XML file was re-imported later. In the atlas template from Lesson 6-1, you may remember seeing bolded words introducing each of the descriptive paragraphs of data. As you can see in your current layout, the XML data itself features no such words, which means you must add them manually to the layout before the template can be complete.

We learned in the cookbook example that cloned text must be inserted outside the tagged placeholders. But unlike in the cookbook, the words you add to the atlas structure will not be on a line/paragraph of their own—they will be in the same paragraph as the XML placeholders.

But before we proceed, we have to take care of a bit of housekeeping. You may have noticed that some of the text has slipped under the anchored frames and become inaccessible. Addressing the problem now will save you some trips to Story Editor or other equally undesirable contortions.

The structure now includes all the text and objects that will be cloned, as shown in Figure 6.10. You’re nearly finished.

Figure 6.10. Note the location of the anchor icons and the untagged text introducing the paragraphs.

By this time, formatting the structure should be second nature to you. If you’ve been paying attention, you understand that formats applied to the XML placeholders transfer to the imported data and then are cloned on each page of the layout. All sorts of glitches can happen to a structured layout as it’s being cloned, and we’ve determined that you preclude most of the problems by creating and applying Paragraph, Character, and Object styles to the structured layout before importing the XML whenever possible.

Paragraph styles have sufficed in our workflow up until now. But to make the atlas and other documents look good, you’ll discover that Character styles are equally important. And the most powerful application of Character styles also happens to be one of our favorite InDesign wündertools: nested styles.

Nested styles, like Lerner and Lowe, or chocolate and peanut butter, are happy confluences of two great things. The tool combines Paragraph and Character styles in an ingenious way that is also ideal for a structured XML workflow. It allows you to apply Character styles automatically to parts of paragraphs based on their intrinsic structure. How much better can it get?

For example, each paragraph of atlas data is introduced by one of the words you typed in Lesson 6-6 (Continent, Description, Population, and so on). In the original template, each of these words is formatted differently than the text in the rest of the paragraph. You could format these words manually and hope they retain the format as the placeholders are being replaced and cloned, but that’s like hoping the tooth fairy will leave a winning lottery ticket under your pillow.

The problem with the atlas is that the introductory words are untagged. Using the tools you have learned so far, there’s no way to guarantee that these words will maintain their formatting during cloning—except by using nested styles.

Let’s see how nested styles work in a structured layout:

Because each of the subsequent paragraphs needs to be formatted identically to this one, we could use the continent style for all of them and map it manually to each of the XML elements. But we prefer to have Paragraph styles named for each of the XML elements.

Note how the New Paragraph Style dialog picks up the formatting of the existing text. But one setting has not been applied yet. As is, the imported XML content will form a continuous text flow filling every text frame top to bottom. That means if one atlas entry doesn’t use the entire page, the next entry will automatically start in the remaining space. Egads! Don’t worry; we describe the solution in “Styles Essential to XML Magic” in Chapter 4.

The structured layout is nearly complete.

For the cloning to work properly when the XML is re-imported, the relationship between the XML tags and the newly created paragraph styles has to be formalized. This is done by mapping the tag names to the Paragraph styles.

Before testing the atlas, let’s save the file.

Nervous? Let’s see if your structured atlas design works.

Quick, it’s not too late to list your socks on eBay!

If you followed the instructions carefully, everything should have worked as in the sample template in Lesson 6-1. If something messed up, first try to identify the error. Next, press Cmd-Z/Ctrl-Z to reverse the process and then check the following items in the structured document for errors before trying it again:

Fix any problems and then try it again.

Although there’s only one way to create a functioning XML workflow, there are unlimited ways of creating a broken one. Lesson 6-11 can help you track down a problem originating in your structured document, but what do you do if the error is coming from the XML itself?

There’s not enough space in this book to discuss every possible error you can encounter in an XML file, but we’d like to show you at least one common problem you may experience and its simple solution.

If you look in the title bar of the dialog you can see that InDesign is looking for a file called us-flag.tif. Unfortunately all the graphics used in this workflow are saved as PDFs, not TIFFs. In other words, a simple typo has ground this workflow to a halt. But, instead of crashing or doing some other undesirable reaction, InDesign politely asks us to locate the missing file. Using this dialog you can track down the actual location of us-flag.tif or simply redirect InDesign to a proper replacement.

If this happens to you during a real project, open the XML file in your favorite editor (see Chapter 3) and examine the file and path names. Make any corrections necessary and save the file.