Got an e-mail from a fellow book designer this morning asking, “Do you have a blog post about marking up a MS for the designer/typesetter?” Um, I couldn’t remember; had to search my own blog to find out. I found I’d written two posts in which such issues come into play—
- May I take your order? (September 30, 2006)—in which I show the sample pages I prepared to instruct a typesetter on a moderately complicated book design
- How stylish are you? (January 19, 2008)—in which I listed and explained the most common style names I use when marking up or laying out a bookish document
But both of these posts are written from the designer’s desk, whereas my friend was, he later explained, looking for information that might help a fledgling editor (in this case, an editorial intern) understand how to mark up a manuscript. To which I said, “Um, hello, the Chicago Manual?” I know there’s some discussion of markup right there in the front, but I realized I hadn’t consulted that section in the 15th edition in years, and I hadn’t yet checked it in the 16th edition at all. So I looked! And found that there is now a sizable chunk of appendix devoted to markup, with an eye toward producing multiple output formats—print, HTML, e-books, and more. That appendix is heavy going, though, and more theoretical than practical. How might a designer or production editor explain, in, say, under twenty minutes, how a clever intern should mark up a manuscript?
Well. I do think the first two paragraphs in CMS16’s Markup section in Appendix A are a good place to start. Key points:
From A.6, “What is markup?”—
There are four basic ways to apply markup. . . . Briefly, they include markup by pencil on paper; generic markup in a word processor, which is similar to paper markup except that it is typed into the document (see 2.78); word-processing styles (see 2.79); and markup in a formal language such as XML (see 2.80). All of these share a fundamental purpose: to identify each element of a manuscript, from chapter numbers to chapter titles, subheads, paragraphs for running text and block quotations, emphasized text, entries in a bibliography, and so forth.
From A.7, “Semantic and functional markup”—
A formal markup language describes the structure of a document and identifies its components. This type of markup is sometimes referred to as semantic markup because it names the parts of a document rather than describing their appearance. To take one example, though the title Origin of Species might be distinguished from the surrounding text by italics, more meaningful markup would label it as a book title. Such markup would not only differentiate book titles from other types of italicized text (such as names of species or emphasized terms) but would allow them to be presented in something other than the customary italics if desired—for example, boldface or underscored. . . . Moreover, some markup may have formatting or functionality associated with it in one medium but not another. For example, markup that determines hyperlinked text—graphically distinct and clickable in an electronic document—may not be evident on the printed page.
In other words,
- it doesn’t really matter how you indicate the style changes, as long as you follow a system that makes sense; and
- mark up what the text is, not what you think it should look like.
That’s the theory. Now how do you practice it? Well, that depends on which method, of the four listed in A.6, you are following:
- markup by pencil on paper
- generic markup in a word processor
- word-processing styles
- markup in a formal language such as XML
I’ve seen the first three used extensively in the wild, but so far I’ve yet to receive a manuscript marked up in XML. Not holding my breath, either; XML is rat simple in some ways, but it can also make people extremely cranky.
Every production editor, designer, and compositor probably has his or her own preferred method, and if you’re working in house or freelancing for a steady client, you’ll use the house method. But at your next job, or whenever the current production chief retires, they’re likely to use a different system, so you should understand the gist of all four. Going through them one by one, therefore . . .
Markup by pencil on paper
This is the easiest and lowest tech, and probably therefore still the most common. There’s an illustration of this kind of coding in CMS16, figure 2.5. The basic idea is to write a brief code in the margin and circle it. It’s what we used at St. Martin’s while I was there, and I’ll bet a modest amount of money (hey, I’m underemployed; gimme a break) that it’s what they’re still using four years later. It’s the method I described in the penultimate paragraph of May I take your order?, which highlights the main drawback of this system:
There’s only one chunk of poetry in this book, but it’s a long and messy one comprising selections from a longer, oddly structured work. The headings on these poetry extracts had all been coded correctly—A and B heads only—on the design dupe in red, and then recoded incorrectly—with three levels of heads—in blue on the setting copy. So I tossed it back on the production editor’s desk with a note asking if it was okay to change them back, and when she said it was, I erased all the (illegible, anyway) codes and remarked them in my color (which is usually brown). Frankly, it’s kind of annoying that the MS comes to me already coded, because quite often I find that the coding is wrong. I spend a lot of time erasing or crossing the codes out and rewriting them.
Should you need to correct the coding, you either have to erase the old marks—which can be difficult, with some varieties of pencil—or cross them out—which can get ugly. I prefer to cross them out and re-mark in a different color, because it makes it easier for the typesetter to tell what’s going on. If I must erase, I do so as thoroughly as possible (using a Mars eraser or a retractable eraser stick—never the eraser on the end of the pencil, which exists solely to torment and dismay) and then write the new mark right over the old one, so the previous code can’t be read.
When using this method, it’s rare to label every paragraph. What styles should you mark, then, and how often? The example in CMS shows only the heads being tagged—CT for the chapter title and A for an A-level head; everything else is assumed to be body text. Unless I’m given specific instructions, though, I prefer to err on the side of . . . well, specificity. I’d add the code TNI (per the naming scheme I described in How stylish are you? [BUT: see my comment below, added while I was actually awake]) next to the first paragraph under each heading, and TX next to the first indented paragraph below each of those. After that, I wouldn’t mark anything until the next change in style. I would also err on the side of semantic distinction. I’ll use separate codes for quoted prose extracts, quoted correspondence, and quoted verse, though they might all end up being typeset using essentially the same style.
Generic markup in a word processor
A lot of people do this in exactly the same way as in method 1, but within the actual file instead of on paper. That is, instead of writing “CT” in the margin next to a chapter title and circling it, they type “<ct>” or “[[CT]]” or “***CT***” at the head of the title itself, and without any space after it. The codes could be wrapped in any characters or groups of characters, as long as they’re not ones that occur in the actual text itself. (Angle brackets are probably a safe choice for novel, as long as it’s not science fiction, but it’d be unwise to use them to tag a book about anything related to Web technology, since they’re likely to appear in examples of HTML.)
Another way to do this kind of markup is with paired start and end tags, as recommended in CMS16 2.78, “Generic markup for electronic manuscripts”:
<cn> . . . </cn> chapter number <ct> . . . </ct> chapter title <a> . . . </a> first-level subhead (A-head) <b> . . . </b> second-level subhead (B-head) <ext> . . . </ext> block quotation (prose extract) <po> . . . </po> poetry extract <note-a> . . . </note-a> first-level subhead in endnotes section <tdotb> t with dot below (i.e., when the Unicode character for ṭ is not available in the font being used to prepare the manuscript; see 11.2) <! . . . !> instruction to the typesetter—for example, to consult hard copy or page image for proper alignment or other formatting
The idea here is that you wrap everything in these pairs of labels:
<ct>How I Spent My Summer Vacation</ct>
tnic1>This summer, I went to Italy with Elisabeth and her family. We stayed a week in each of two separate towns.</ tnic1>
<tni>For the first week, we—Elisabeth, her husband, their two daughters, Elisabeth’s parents, and I—stayed at a resort tucked amid the hills of Tuscany. At the top of the nearest hill sat the tiny walled town of Casole d’Elsa.</tni>
<tx>We spent a lot of time at the pool.</tx>
Depending on your familiarity with and loyalty toward HTML, this markup system may look comforting or terrifying. Or something in between, which is where it sits for me. It’s my feeling that if you’re going to do this much markup, you might as well aim for valid XML. But if it serves as training wheels for less tech-y publishing people who’re trying to make that transition, that’s worthwhile, too, I guess.
This method is described in general terms in CMS16 2.79, “Software-generated styles.” As implemented specifically in MS Word, it has been my preferred method for the last, oh, fifteen years, ever since my programmer friend Steve showed me his super-secret method for quickly applying Word’s built-in styles (which I think was a custom control panel, written in Visual Basic? that supported keyboard shortcuts?). That was in Word 95 for Windows, mind you. MS Word has supported styles since forever, but most Office users still have no idea they exist, much less how to take advantage of them. And a lot of the best ways of taking advantage of them depend on automation, which is a lot less idiot-friendly since Microsoft killed off macros in Office 2008.
Styles are by no means unique to MS Word. RTF documents can contain styles, too, and most modern word processors can read and write RTF, if not .doc files. I’ve yet to find another program that makes styles as easy to use as Word does, though.1 And by easy, I mean fast. And by fast, I mean keyboard-controllable. I really don’t want to have to keep switching between keyboard and mouse when I’m doing something as repetitive as styling a book-length manuscript.
So I’m still using Word 2004, and I have no idea where you’d find the equivalent controls in the newer versions with the “ribbon” interface. In general, though, the process would be as follows:
- Set up some styles. This can be tedious, if you use as many styles as I do, but you need only do it once, and then you can save the whole wad in a document template. I tend to use a lot of colors and fonts, to make the styles easy to distinguish at a glance. Since I’m just going to map them over to corresponding styles in InDesign by name, it doesn’t matter how hideous the Word doc ends up looking. If you’re coding an MS for somebody else, you might want to avoid the psychedelic ransom-note look, though.
- If the MS contains reasonably consistent localized formatting (e.g., all the A-level heads are bold, and all the B-heads are bold and italicized), use the “Select all” button in the formatting palette to apply styles to identically formatted noncontiguous chunks.
- Use search-and-replace to apply styles as thoroughly as possible to less consistent localized formatting.
- Use macros to apply styles to other weird but semiconsistent stuff. For example, if all the chapter titles are in all caps, and each one is preceded by a chapter number and followed by an epigraph, I might record a macro that searches for text in all caps, moves the cursor to the head of the line and applies the CT style, moves the cursor up one line and applies the CN style, and then moves the cursor down two lines and applies the EPI style. I’d then step through the document, styling the first three elements in each chapter using this macro.
- Once you’ve applied as much styling as you can through automation, check the whole document page by page to deal with whatever you’ve missed. When you’re done, nothing in the document will be styled as “Normal”; every distinct type of element in the text should have a named style attached to it.
(All that said, even though I’m still running Office 2004 so I can keep my blessed macros, lately I’ve been doing more of my styling in InDesign. It’s faster to do so using InDesign’s QuickApply than it is to use Word’s formatting palette or the style dropdown on Word’s formatting toolbar. But if you’re an editorial intern who’s being tasked with coding a manuscript, you don’t have that option, so tough luck.)
Markup in a formal language such as XML
Weeeeeell, as I said, I’ve never personally seen this used on a real project. So although I’ve been wanking around with XML for years, and I could explain it in a general way, my description of XML markup as it’s used in publishing would be, at best, a SWAG. There’s some interesting stuff at Start With XML, but it seems geared more toward management types than toward us lowly manuscript monkeys, and there’ve been no new posts on the blog for more than a year.
So I’m going to pull a Butterfly McQueen and say, “Lawzy, we got to have a doctor! I don’t know nothin’ ’bout birthin’ [XML] babies!” Anybody know of a good how-to-XMLize-books resource that’s adapted to the meanest understanding—or, at least, to the small-press level of meanness? If you have actual battlefield experience with this, care to drop some knowledge in the comments?
No matter which markup method you use, be sure to make a list of all the styles you ended up applying, with explanations as necessary. Keep your style names short, but don’t make anybody have to guess what they stand for.
Phew. Epic. Any questions? Anyone? Bueller?
- Any recommendations? And don’t say NeoOffice; I use it sometimes, but it makes me sad. [↩]