By David Alan Rech of Scribe Inc.


Many of us in the publishing industry use the term quality regularly. When we talk about quality, we mean that publications are free from error—that they appear to be correct. We edit, proof pages, proofread, and make and verify alterations, all in an effort to create quality publications. We judge our staff, freelancers, and vendors by the number of errors they allow (actually, the number of errors found in subsequent stages—we may not know the actual rate). A lower error rate seems to indicate higher quality.

All the metaphors and methods we employ to gauge quality are associated with our vision. A person has a good “editorial eye” if she is able to catch and correct errors. We disqualify people if they fail to see things. We check manuscripts, PDF page proofs, and e-books by using our sight—by reading. In the old publishing model, we relied on our eyes to catch things because what we saw was all that mattered. I suggest that these methods are completely insufficient for the current state of our industry and that we should rethink the entire concept of quality.

Yes, a book’s content must be free from error. But it’s no longer sufficient for a book to merely read well. In a world in which publications appear in various formats, books must function in multiple platforms, the underlying code must be correct, and the content must be easily repurposed. In the contemporary world, much of what can cause error cannot be seen with our eyes. This can be illustrated by some common occurrences in e-books.

Hyphens and spacing sometimes seem elusive in e-books. In a number of e-books I have seen, hyphens are either missing (e.g., “This is an ahead.”) or incorrectly inserted (e.g., “She finished way a-head of me.”). Similarly, spaces seem to disappear regularly (e.g., “She got ahead wound.”). In almost every instance that this occurs, the printed version was “correct.”

Often, what I refer to as a “rogue element” will appear. Electronic books will have individual instances of an element that appears in an entirely distinctive way from other instances of that same element. For example, a head will lack the rendering treatment afforded to all others in the chapter (font, alignment, thickness, and the like). Or one element will be disproportionately larger than all other instances of it. Other examples include apparent case changes from one identical element to another, incorrect case application from the print to the electronic version, misalignment of paragraphs,* inconsistent section breaks, and odd paragraph breaks.

In most cases, these types of errors are the result not of proofing problems but of structural issues in the files. Even if visual examination can catch these problems, the quality issue is located far upstream. In many cases, visual examination cannot properly identify issues. Occasionally, there is almost no way to catch a problem downstream without repeating a complete visual check (and even then, you might have problems). As an example, it is visually impossible to tell the difference between a discretionary hyphen and a hard-coded one. A misplaced hard-coded hyphen can cause issues downstream if it is inadvertently removed or left in. In actuality, the distinction between these two types of hyphens is lost in PDF. Worse, because of the reflowable nature of e-books, the problem might not present itself in the individual check that is performed. The misuse of hyphens, or numerous other problems, can remain undiscovered by the publisher. These errors are caused (or allowed) in the editorial or print production stage. They are not postproduction vendor problems. Instead, these are errors that were missed in page proofs—by people relying on their eyes. As we consider this problem, it becomes apparent that it is almost impossible to rely solely upon our eyes to assure quality. A new set of expectations and corresponding checks must be established.

To achieve quality, we must consider the requirements of our publications. A book must have a number of features. First, it must read well and be free of grammatical errors. The files that we create must be built well to ensure that ad hoc problems don’t show up downstream. Files must be readily converted and must work within a variety of different output formats. In other words, our books must be both visually and structurally sound. We are good at checking for language integrity, but we need to learn to check for more if we are going to achieve quality in our publications. We must also learn to examine publications for application and content integrity.

Application integrity means that content is properly constructed within the software in which you are working and can be seamlessly moved into other applications. This is usually achieved with the correct use of Word and InDesign. A review of application integrity must be done within the application itself and not in some other format (i.e., you cannot perform application integrity of InDesign files using PDF).

  • You should open files in their applications and examine them carefully: view all the components of the files, including styles.
  • You should always view files with hidden characters shown. This will let you see how files are set up. The corollary to this rule is that you should not rely solely on your vision to review the file.
  • You should develop searches and computer methods to catch application integrity issues. Your eyes cannot catch what the computer will.

Content integrity means that all content is present and treated well. We must develop methods to make sure that all paragraphs are present, all files are laid out correctly, and all styles are properly employed.

  • Paragraphs need to function as a continuous whole and must not be broken manually in ways that will cause formatting issues in future versions.
  • Proper layout means that styles and rules dictate how things appear. Multiple spaces, tabs, carriage returns, and other methods should not be used to achieve proper layout. Proper layout also means that print- or version-specific elements are handled in automated ways. For example, discretionary hyphens should always be managed through the software’s automated features, not manually. If you have house preferences, editors and typesetters can create and use dictionaries that can be shared among your staff and freelancers. And hard carriage returns should never be used for discretionary line endings.
  • Every content type should have its own style name, and all styles must be applied correctly and consistently. No separate element should carry the name of a different element: this is especially important when elements that have different structural functions (i.e., a poem and an unnumbered list) are designed the same way. And no named style should be modified to represent another element: each separate style must have its own name.

Publishers must take several steps to assure that the quality of their publications meets the requirements of the contemporary world. Yes, you need to have good copyeditors, typesetters, and proofreaders. But you also need to establish practices for how things are to be done and communicate those practices to everyone involved in creating your publications. You have to develop enough familiarity with the applications used to perform the computer-based checks. And you must develop a set of processes to assure that you have both application and content integrity.

In future newsletters, I will be discussing quality assurance (QA; a system in which standards, tolerances, and performance are established and attained) and quality control (QC; tests to confirm that QA is being accomplished) as they specifically relate to our publishing world. For now, it is important to understand that we can no longer rely solely on our eyes to catch errors. We must develop practices beyond the visual checks to assure that our publications are of high quality.

* The alignment issue is a particularly good example of the insidious problems referred to in this article. In previous years, e-books contained a greater number of these problems than we see today. However, the cause of the problem has yet to be addressed. The reason for the improvement is that vendors have become better at correcting the errors caused by upstream practices.