Editors on the production side of publishing–often called project editors or production editors–coordinate and/or oversee the work of authors, copyeditors, proofreaders, and designers as a manuscript that has been accepted for publication is turned into a book. Often this involves direct copyediting and proofreading, but it also involves lots of letter writing, instruction, and art and permissions verification and organizing.
In my early days at another press, one of the most challenging parts to this job was writing the design memo. There, I dealt with a lot of textbooks, most especially first-year foreign-language guides and English handbooks. Monographs, on the whole, tend to be simpler in terms of the number of discrete elements that go into a design, and so design memos are generally much shorter and more easily written.
The design memo is a list of the elements that go into any particular book design. Much as any page on the Internet consists of a number of textual items that receive a separate code so that they look different, so too each different-looking item in a book is identified, tagged, and designed. (Tags might also be called codes, typecodes, or keymarks.) At its most basic level, a book (as do most web pages) has text (which here at UGA we code as TXT): the body of the book, where most of the discussion takes place. But that text is often broken up by other items that help readers to better navigate the material–for example, chapter numbers, chapter titles, and first-level subheads (CN, CT, and H1 respectively).
Determining what elements make up a book design can become challenging when the number of elements proliferates, most especially if there are a lot of nonstandard elements. Take, for example, UGA’s most basic code, TXT–standard body text. There might be multiple types of text. If there are boxes or sidebars, each of those might be coded differently to denote that the text should be boxed. If there are different kinds of boxes, each type of box text might receive its own code in order to differentiate the types of text from one another. Or perhaps the author wants some text to be set flush right, some justified, some centered, and some flush left–all of those might well receive a different code to distinguish them as separate elements. This is easy enough to do, but now add in text that may indent a quarter inch, some half an inch, some a full inch, and so on: a large number of potential codes can begin to make it difficult to identify particular elements and to tag them properly.
Determining what the author’s desire is with regard to the final look of the book, thus, can become one of the great quandaries to resolve as part of creating the design memo and of coding.”
The latter situation happens quite often when we attempt to create design memos for experimental poetry. Every line in a particular poem might well have its own set of parameters in terms of alignment, font, leading, and size. It can also happen in other fields. Authors might, for example, use a variety of symbols to separate sections of text (e.g., an asterisk, a string of asterisks, a line space, a string of angle brackets) or different types of bullets in various bulleted lists (a black dot, an arrow, a white dot). Sometimes the author intends for the publisher to print the book with these variations; other times, authors have simply not been punctilious about representing their intentions in a consistent manner. Determining what the author’s desire is with regard to the final look of the book, thus, can become one of the great quandaries to resolve as part of creating the design memo and of coding. If an editor decides that all those different types of symbols in fact mean the same thing or that all the different-sized fonts in fact are intended to be the same size font, only one code might be specified on the list of design elements. If the editor guesses wrong or fails to query the author, problems may arise later in terms of trying to distinguish between differing elements (if there are too many codes) or in terms of unifying the differing elements (if there are too few codes).
Often, when a particular book is really experimental, rather than creating or finding a code that will work, I simply offer design and typesetting instructions for the particular piece or part and provide a copy of how the author originally rendered it. I also try to denote what is negotiable and what is not (that is, the author might mostly be concerned about the space between his or her words in one passage but not about their actual haphazard alignment, or the author might want to use a particular type of font for the words that appear in the center of the text page but doesn’t care which words actually fall there).
Two recent books that featured a number of challenges in this regard here at the University of Georgia Press were Dustin Parsons’s Exploded View and Michael Martone’s Brooding. Parsons’s book featured lots of graphic art that he superimposed his own writing onto as a kind of metatext. Sometimes the writing sat alongside the art; sometimes it became part of the art; often the writing needed to fall in particular places (directly under, directly to the side). For that book, I often ended up doing exactly as I described in the paragraph above. While not as graphically oriented, Martone’s book was in line with the kind of work that Martone often does, joying in the challenge of breaking the rules set forth by writers and book makers. In one piece, pages are left blank along the right side, with images centering. Another piece includes footnotes, end notes, and footnotes and end notes to those footnotes and end notes, as well as notes to those notes and notes to those notes–more levels than a word-processing program can handle. As such, the piece required me to set up a system whereby the typesetter could distinguish which notes went where (e.g., this note should go at the bottom of this page where this note appears; this note should drop to the back with the first set of end notes; this note should appear at the bottom of the page under this first set of notes that also appears at the bottom of the page, etc.).
Often, when a particular book is really experimental, rather than creating or finding a code that will work, I simply offer design and typesetting instructions for the particular piece or part and provide a copy of how the author originally rendered it.”
Luckily, most of our books are fairly standard in terms of the elements that they include. This saves us a lot of time in terms of creating memos, coding the manuscript itself, and ultimately designing and typesetting it. In recent years, the development of XML has allowed for the repurposing of content such that codes now often are not just focused on design but also on what the text actually says. Robust coding, for example, can allow a publisher to pull out specific words and page numbers from which to create a rough index. As such, many publishers have attempted to standardize coding across books so that particular elements can be pulled out and repurposed.
Here, at the University of Georgia Press, we use design templates for many of our books, allowing us to flow well-coded manuscripts into designs we already have on hand; this saves us the time and cost of creating new designs for every book. “Odd” books with odd elements are fun insofar as they allow us to stretch our skills in new ways, but too many of them can put a strain on our systems and add significantly to our workload. When authors stick to the preset list of elements we provide to them during the creation of their final draft, we are more easily able to publish their books on time and within budget so that readers can have access to the author’s ideas earlier, and this makes all the parties involved happy.
Jon Davies is assistant director for editorial, design, and production at UGA Press.