“Creating a Workable Book Publishing Workflow,” by Susan Daffron (November 2012), included some excellent advice about how to use styles to efficiently format text for multiple platforms, and it talked about importing Word styles into InDesign. The author mentioned that her company uses InDesign from Adobe’s CS3 software bundle.
Our company provides editorial, production, and project management services to publishers, and when we “upgraded” to CS6—the current version of this software, which includes some changes in functionality that have a dramatic effect on how styles are imported—we experienced significantly reduced productivity and increased frustration. For others who might be using the newer software, here’s what we learned about the challenge and how to work around it.
As the article mentioned, when using CS3 it is possible to use bold and italics in Word files, and these text attributes (known as local formatting) will be retained when styles are imported and mapped to styles in InDesign. When Word styles are mapped to their appropriate InDesign counterparts by the same process in CS6 (and CS5), all features of the Word style are retained as local formatting. This includes items such as font, font size, paragraph spacing, and even hyphenation and justification. Unless styles are initially designed differently from what was required in CS3, the newer versions of InDesign apply all these elements as local overrides to the InDesign style.
Here’s an example: Suppose your author produces a manuscript in Word using a style “Regular,” where “Regular” appears in the font Times New Roman, is not justified, and has hyphenation turned off. In addition, let’s suppose your author uses italics to introduce key terms. In CS3, you could import this text into InDesign and have the “Regular” style appear in the font Palatino, with justified text, and with hyphenation turned on. The italics that had been applied within the text would be retained as local overrides, so the words would still be italicized.
In CS5 and CS6, when this same text is imported and mapped to the style “Regular,” everything is retained as a local override: the wrong font, the incorrect justification, the lack of hyphenation, and the application of italics. These local overrides can be turned off (so that you get the correct font, etc.), but this is an all-or-nothing proposition. Turning the overrides off means that any applied text attributes (bold, italic, superscript, etc.) will disappear too. These types of items then have to be manually reapplied on an individual basis throughout the entire manuscript.
After spending a considerable amount of time reading online forums where others discussed this problem and after doing some experimenting with our files, we learned that this can be fixed by changing the way styles are built and defined. In the past, it was possible to use a basic style and create other styles based on it. For example, you could have a style called “Regular” that would define the way regular text would appear. If you had another style for indented text, you could call it “Indented” and base it on “Regular” with just the indent being different.
The advantage to using styles that are built on one another is that you can make global changes to common elements simply by adjusting the underlying style. For example, if you want to change the text of a book from Palatino to Bookman, all you have to do is change the base style and the adjustment flows through to other styles built on it.
But when styles are created by building on and modifying other styles, the newer versions of InDesign are unable to distinguish true local formatting (such as bold, italic, and superscript) from changes that are intended to differentiate one style from another (such as font size, indenting, and paragraph spacing).
The solution is to modify or build all styles so that they are based on “No Style” in Word and “No Paragraph Style” in InDesign. Although this solution means that universal changes cannot later be made to a single base style (each style has to be changed individually if such alterations are needed), it does solve the problem of retaining only intended, true local formatting.
In our experience, the process of applying global changes to multiple style definitions is much more manageable than the process of trying to identify each instance of a missing text attribute.
Additionally, we have discovered that the importing process works best if Word files are created in the .docx format (rather than the older .doc format).
Karen Bellenir is Editorial Director at Wordwright, LLC.