|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2024 --> Editing in Acrobat
Vous êtes ici : Essais --> 2024 --> Editing in Acrobat
by Geoffrey Hart
Previously published as: Hart, G. 2024. Editing in Acrobat — Just don’t go there! American Editor Dec. 6/24.
In mid-1993, the first Adobe PDF file escaped the primal nöosphere, seized its first victim in formidable jaws, and dragged it back beneath the collective subconscious to feast upon the victim’s still-twitching corpse. (Forgive my purple prose: when I wrote this, it was during the lead-up to Halloween.)
I keenly recall the conversation I had that year with an Adobe employee (if memory serves, Adobe’s Canadian program manager) who had come to Montreal to present the new technology to us. He seemed particularly pleased about Acrobat’s ability to run .exe (executable) files automatically when a PDF file was opened. I disingenuously asked him whether that was also true of programs such as the MS-DOS “batch” command “delete c:\*.*” (i.e., delete everything on one’s hard drive). He blanched, jotted down a note, and rapidly changed the subject.
Since then, and as I write this, representing a period of 30 years, I’ve been one of the relatively few Acrobat skeptics and an increasingly vociferous objector to the concept of editing manuscripts submitted in PDF format. What Acrobat does well, it does very well indeed. I rely on it for publishing my books and distributing documents whose format is nearly as important as their content. Unfortunately, editing is not one of the things Acrobat does well. Worse yet, Adobe periodically changes the interface — as far as I can tell, specifically to annoy us all.
Note: To be sure we’re working with the same definitions, I’ll define editing as fixing grammatical errors and improving the clarity of a manuscript. In contrast, I’ll define proofreading (proofing) as looking for any small errors that somehow escaped the review and editing process so we can ensure the final output is correct and correctly formatted.
That being said, in this article, I am come not to praise Acrobat, but to bury it (again with the Halloween esthetic!) — at least for editing. For an opposing viewpoint and a great many useful lessons for editors who have been asked to use Acrobat to edit, I recommend the Acrobat resources Adrienne Montgomerie provides on her website.
Having said that, and having freed myself from the responsibility of providing a completely balanced and objective perspective, I’ll tell you why I recommend that you avoid editing in Acrobat wherever possible.
So: Why avoid Acrobat for editing and reserve it strictly for proofreading? Because editing in Acrobat is inefficient and increases error rates.
If you’re editing in Acrobat, the first problem you’ll encounter is that you don’t have access to any of the customizations you’ve spent years developing for the word processor you use for your daily edits. These customizations greatly accelerate editing, and if they’re well implemented, they also decrease error rates while improving the quality of our work, particularly when it comes to imposing consistency on a manuscript. I can’t imagine completing as much work as I do in a day without the customizations I developed to support the specific type of work I do in Word — yet Acrobat eliminates all of these tools and provides no suitable replacements for them.
To make matters worse, kickass tool suites that go much farther than my primitive efforts, such as Editor’s Toolkit Plus and PerfectIt, simply won’t work on a PDF file.
If you’re sufficiently geeky, you can get around some of the missing tools by using third-party software that creates macros that will work on all programs that run on your computer. Popular choices include Macro Express for Windows and Keyboard Maestro for the Mac, both of which offer considerable power to automate the workings of your whole computer, as well as specific programs such as Word. But you need to buy them, study them, and spend time mastering their power. And it’s not always obvious how to accomplish some things that are trivially easy to accomplish with a word processor — because Acrobat isn’t a word processor.
Acrobat itself offers few of the highly refined tools offered by word processors; for example, Acrobat’s “advanced” search function isn’t. It’s frankly primitive compared to the power offered by most word processors. Even if Acrobat’s search function meets your needs, few of us have the time or ability to figure out how force it to do what we want using a third-party program. Which might be less of a problem if Acrobat provided built-in support for creating and running macros — but it doesn’t.
The final inefficiency is that no matter how fast you manage to work in Acrobat, editing in it requires that every editorial change be made twice: once when you, as editor, spot a problem and propose a fix, and a second time by the person who copies your revisions into the program used to generate the PDF file. (To add insult to injury, it’s generally much faster for us to simply make a change than it is to tell someone else how to make the change. But we can’t do that in Acrobat because our edits wouldn’t affect the original file used to create the PDF.) It’s simply not possible to eliminate that second step that updates the source file and allows the creation of a new, corrected PDF. But that second step doesn’t just increase the time: it increases the error rate.
Speaking of which...
Handling the same corrections twice potentially creates twice the opportunity for errors. Each person who modifies a file has their own personal error rate, and these rates are additive as you add participants to the revision process. We editors tend to be very fussy about our work, so our error rates tend to be low; they are not zero, however.
The person who transfers the edits into the original program used to create the PDF has their own error rate, and they’re usually less skilled than we are. Why? Because we’ve spent many hours honing our skills and are extremely fussy about doing our work right the first time. Even authors whose primary role is to write spend less time revising their manuscripts than we spend editing them, so their revision skills are usually weaker. The problem’s worse for people like managers and engineers for whom writing is at best a secondary task. Their error rates may increase further if (i) they’re prioritizing the need to get a manuscript off their desk rather than focusing on quality control, (ii) they do this kind of work too rarely to develop high proficiency in the transfer of edits, and (iii) they misunderstand an edit and therefore make the wrong change.
At the start of my career, back in the dark ages of editing, my employer was one of many who employed a dedicated pool of professional typists — the equivalent of medieval monks laboring to copy manuscripts in a scriptorium — who spent their days transcribing authors’ revisions into their manuscripts. I (or the author) would then compare the handwritten edits with a printout of the revised manuscript to ensure the changes had been made correctly and none had been missed.
The best of these typists had an accuracy of about 95%. (Treat that number as suspect. I calculated it more than 30 years ago, and my memory is growing imperfect as I get older.) That success rate may sound pretty good, but if I only made 20 changes on a page (and as a substantive editor, I usually made many more), that meant one error per page — and the success rate was often much lower, among other reasons because my handwriting was — and is — nearly illegible. For heavily edited manuscripts, such as when I did both substantive editing and copyediting, it wasn’t unusual for a manuscript to travel between me and the typist three or more times until all corrections had been implemented correctly. If the author reviewed my work before sending the manuscript for retyping, their comments and corrections frequently overlapped my edits, making it even more difficult for the typist to figure out which correction was correct. This further increased the error rate — sometimes greatly.
Now that authors almost universally do their own corrections of manuscripts, the problem has changed form but not vanished like a ghost before the dawn.
Transferring edits into the original program that created the PDF file is particularly important for any document that will be revised frequently, and even for some documents that may only be revised once or twice. In each case, the revisions must occur in the original program that created the PDF file. Acrobat doesn’t automatically reflow text if (for example) you try to move words and sentences to new positions. That means you’ll need to regenerate the PDF after each round of corrections and re-proofread it to ensure that the original edits were correctly implemented and didn’t create new problems, such as moving only part of a sentence or moving it to the wrong location.
Speaking of errors, one of the most fundamental types is failing to implement a sound backup strategy. In the 30+ years of Acrobat’s existence, I've long since stopped counting how many times I've read desperate pleas from authors seeking help because they (or their managers) had deleted the original file used to generate the PDF once they had moved all the text into PDF format — only to discover that because they had no backup of the original file, they could not correct and regenerate the PDF file.
This happens far less often today, and Acrobat does have some text-export abilities, but having to extract text from Acrobat, pour it back into that original application, and reapply all the lost formatting is both time-consuming and error-prone.
A far better approach requires us to step back and reconsider the goal of producing a PDF file: to provide a manuscript that will look the same on any computer and will produce identical printouts from any printer. That is, PDF files should be finished products, not works in progress. And for that purpose, Acrobat is a superb piece of technology. What it isn’t is a text-editing program, a page-layout program, or a graphic design program. What this tells us is that we should aim to edit a manuscript to near perfection before we transform it into a PDF file. If we accomplish this, we are no longer editing the PDF: We’re proofreading it.
At my former employer, we solved these problems by editing heavily before we sent a manuscript for layout. By the time a manuscript reached the PDF stage, it had been edited to perfection, and if the writer, editor, and manager who approved the manuscript really did our jobs well, all that remained was to quickly read through the text looking for any minor errors that escaped editing, then review the layout for problems such as bad line breaks and inconsistent formatting. That is: All editing was long since done, and all that remained was proofreading. There was little need to return to the program that generated the PDF file because there were few changes required, and the required changes were mostly related to layout.
I can't tell you how much time that saved us. Well, I probably could, but I’d have to exhume some 25-year-old Excel file and extract the statistics, all the while hoping that the guardians of the cemetery didn’t spot me. (As the cemetery metaphor reminds us, life’s too short for such activities.) This approach also maintained or improved the quality of the final layouts. Again, I’d have to exhume ancient files to obtain the necessary statistics, but the gist of the process revision was this: When we decided to improve our publishing process, we tracked several categories of error at the layout stage before and after implementing the new approach. We found that the error count was either stable (indicating that there were certain classes of error that I kept missing and needed to pay more attention to when I edited future manuscripts) or improved.
Warning: Both of my claims should be treated as anecdata, since the data is for only one editor (me) in one publishing context, without replication. But if you think about what I’ve written, the logic and its implications make good sense.
Does this rant against Acrobat mean you should never edit manuscripts in Acrobat? Not at all. Particularly for short manuscripts and manuscripts written by authors working within a formalized review and revision system that incorporates serious quality-control procedures throughout the writing and revision process, the number of edits may be sufficiently low that the problems I’ve described only slow the process slightly and don’t introduce additional errors. Sometimes an author will add or delete a handful of words and leave the rest untouched. But I see so many editors asking for advice on how to deal with manuscripts submitted for “proofreading,” when what is really needed is copyediting or even substantive editing. That suggests their clients need to rethink their publishing processes. As editors, one of our jobs should be to educate them to better understand the roles of PDF files in publishing.
To learn more about some of the publishing process innovations I’ve glossed over in this article, please consult the References section.
Hart, G. 2001. “Backing up” doesn’t mean retreating. Techwhirl. http://www.techwr-l.com/techwhirl/magazine/technical/backups.html
Hart, G. J. 2001. Inspiring reviewers to review your documents. http://techwhirl.com/columns/inspiring-reviewers-to-review-your-tech-writing-documents/
Hart, G. 2006. Designing an effective review process. Intercom, July/August 2006:18–21.
Hart, G. 2007. Demonstrating the value of editing. Corrigo, newsletter of the STC Technical Editing SIG, Vol. 7(1), March 2007.
Hart, G. 2012. Revising the review-and-revision process: a case study of improving the speed and accuracy of technology transfer. Intercom, February:22–27.
Hart, G. 2019. A framework to change old processes or implement new ones. Part I. A framework for managing change. Techwhirl. https://techwhirl.com/a-framework-to-change-old-processes-or-implement-new-ones/
Hart, G. 2019. A framework to change old processes or implement new ones. Part II. Helping people to change. Techwhirl. https://techwhirl.com/a-framework-to-change-old-processes-or-implement-new-ones-part-2/
©2004–2025 Geoffrey Hart. All rights reserved.