Help  |   Contact Us  |   About Us  |   News and Events
Books, conferences, and other information about... Moving to Linux Switching to OOo Building Linux Apps Using Visual FoxPro
Buy      Download      Your Account      Catalog      Support      Conferences      Resources      Fun

Resources - Write/Edit for Hentzenwerke

Wanna write or edit a book? Here's all you need to know about how the publishing process works here.

Write/Edit for Hentzenwerke
Doing the Writing and Editing

Supposing that the proposal and contracts have been accepted and all, now it's time to write. All writing is done in Microsoft Word. As of mid-2003, we've switched from Microsoft Word to's Writer. Authors and Editors are encouraged to use OOo as well - there are versions for both Windows and Linux, but if you prefer to use Word, that's OK. We've been swapping files back and forth for nearly a year, and have found very few problems.

We have a Style Guide and a Word template (part of the Hentzenwerke Author Kit) that you’ll use to create your chapters. The link is at the end of this document.

Let's suppose the players are Al Novelist and Andrea Writer (the authors), Terry Technician (tech editor) and Carmen Careful (copy edit and layout), and the book is called There's Something About Data (TSAD).

First thing that happens is that the authors create a set of folders on their computer, like so:


Source code for each chapter goes in its own directory, while all of the chapters for the book go into the same directory. The naming convention for the chapter files (explained in just a few moments) will ensure that everyone can keep the chapters straight even after there are dozens of them in one directory.

Now on to the writing.

1. Al creates a new DOC file using the Hentzenwerke Publishing .DOT template, turning revision marks ON. Al writes the first draft of Chapter 1 of the book There's Something About Data, and names the file TSAD01_01AN.DOC. "TSAD01" stands for Chapter 1 of the Data book, while "01AN" stands for revision 1 by Al Novelist. (Note that the revision starts with a leading zero "01", not just a solitary "1". This is because it regularly happens that revisions go past 9, and then it's easy to lose track of the most current version because they're not properly alphabetized in file listings. This is important, folks!)

2. Al sends this first draft to me for a general review. The purpose of this review is for me to look at the content and style of the writing. As I've said before, I'm very, very picky about the books we produce, and having a pass at the material this early helps weed out problems when it's easier to fix them. This step is particularly helpful to new authors who are still learning the ropes as far as writing. I'll also note any problems with respect to the style guide. I'll make annotations as well as revisions in the text, name the new files TSAD01_02WH.DOC, and return it to Al. I try to get this file back within a day; sometimes it takes two days.

3. Depending on the severity of the feedback, Al may revise his work and return it to me for a second once-over (although, I guess, it wouldn't be a 'once over' then, would it?). This usually doesn't happen, but it's an option available to the author.

4. Once Al and I have finished our back-and-forth cycle, Al sends it to Andrea, named, for example, TSAD01_05AN. 

5. Andrea makes a copy of this file, naming it TSAD01_06AW.DOC. She reviews the chapter, makes changes, asks questions, and so on. Sends it back to Al. 

6. They go back and forth a number of times, as many times as they feel they need to. Perhaps just once, perhaps a half dozen times or more. 

7. At some point, Al finally decides the chapter is pretty darn good and calls it quits with the back and forth business. Andrea is relieved to not have to listen to Al whine any more. Al accepts or rejects all revisions as appropriate, names the file TSAD01_09AN.DOC, and sends it to Terry for tech edit. Note that at this point, the document is completely clean of editing notes from both authors. In other words, the last author to have touched the document accepts all revisions.

The only time this would not be true is if the book is being written during a beta cycle and an author needs to check on something in a future release of the beta. In this case, the author marks the item to come back to like so:

     *\\\ Is this supposed to work like this? Check back during beta 2///

8. Terry gets the file, makes a copy named TSAD01_10TT.DOC, and makes sure revisions are ON again. Terry tech edits and returns the chapter to Al.

9. Al and Terry might have a couple of go-arounds. Or they might not. At some point, Al will decide that the chapter is DONE-DONE-DONE. He accepts or rejects all revisions as appropriate, saves the chapter as TSAD01_11AN.DOC, and sends a completely clean copy to Whil for copy edit. 

Note that by this point, the chapter should be perfectly (well, OK, fairly well) formatted. It doesn't have to be perfect, but the better it is, the less work has to be done in Layout, which will then help the author(s) make more money in the long run.

Important: Also note that Al, Andrea, and Terry are all submitted weekly status reports to Whil using the status report form found in the Hentzenwerke Author Kit at the end of this document. It is critical that each author and editor communicate with me on a weekly basis about the progress (or lack thereof) they're making against their schedule. The very fastest way to get on my bad side is to fail to report in once a week. Occasionally an author falls behind, and feels that by hiding, they'll somehow become invisible. Bad idea. Really bad idea.

10. Whil sends the chapter to Carmen for copy edit. Her responsibility is to turn the author's document into finished English prose. She will also review the document for other corrections, such as correct figure and table numbering, proper use of styles - anything that will help the chapter get closer to layout.

She makes a copy, naming the file TSAD01_12CC.DOC. She turns revision marks on and copy edits. Copy edit means both turning the author's document into finished English prose and reviewing the document for other corrections, such as correct figure and table numbering, proper use of styles, and anything else that will help the chapter get closer to layout. Once done with copy edit, Carmen will return the file to Whil, who then passes the file back to Al. The edits that Carmen has made are visible, and she has probably asked the author questions that the author has to answer.

Typically, Carmen will have made some changes that the author will need to review to make sure that the original meaning wasn't changed. Additionally, Carmen may have some questions about intent or a lack of clarity somewhere. Remember, Carmen, while experienced with technical document editing, and generally familiar with the subject matter, is not an author or a programmer, and will need to rely on the author's technical expertise.

The Al will answer any of the questions raised by Carmen, review the copy editor edits, and return the chapter to Whil. The next time Al sees the chapter, it'll have been laid out and ready for printing.

11. Al makes a copy of the chapter, naming it TSAD01_13AN.DOC. Revisions are turned ON and are visible in the file. He reviews the chapter, answers the questions from copy edit, and leaves edits alone if they're OK or changes edits that he doesn't agree with. He sends the chapter back to Whil, who sends it back to Carmen for layout.

12. Carmen does layout. This is usually done in large chunks, rather than at a discrete chapter at a time. She goes through an entire chapter, reviewing changes to copy edit questions and edits, accepts or rejects all revisions as appropriate, numbers the pages, takes care of headers and footers, ensures that references to other chapters are accurate (sometimes chapter numbers change order or disappear altogether), arranges graphics, and so on.

Carmen asks the authors directly about any last minute changes instead of passing files back and forth.

13. Carmen produces PDFs of the book and sends them to each author (and the tech editor, if the tech wants) for final review. These PDF files are what will be going to the printer (they convert the PDF file directly to film), so it's the last chance for the author to verify what's being printed, and to make any last minute changes. Experienced authors know this step as "author review of page proofs". Last minute changes are frowned upon at this point, as we are anxious to get this book printed. At the same time, if there's something wrong, now is the time to correct it.

If the authors or tech editor see anything that has to be changed, they correspond with Carmen via email.

14. Once Carmen has heard back from all authors/tech editor that the book is OK (or received all changes), she will make those changes, produce one final PDF, and send it to Whil for delivery to the printer.

Publisher Input: What happens when Paul Publisher reviews one of the chapters after it's been tech edited (or even copy edited), and has a bunch of new questions? First of all, delays caused by this circumstance do not negatively affect the author's schedule, since this is out of the control of the author or editor. 

There are actually a couple sub-scenarios (is that a word?) here. In the first case, if an author is nervous about what they're writing (first-time jitters, for example) or if I am particularly interested in details of a topic, we all should build in time for my review. Ideally, that would come before tech edit - in fact, most ideally, even before co-author review - as noted earlier.

The second scenario is when I review a chapter after it's been through copy edit. This doesn't happen often, but when it does, the author typically becomes quite annoyed with me. This can delay the book because the author may feel the need for a second tech edit. In practice, there's not a need for a second copy edit - any revisions will be copy edited at the same time layout is done.

Dates: Note that the final chapter is to be submitted to me by the date on the schedule. That means that the author should plan on enough time for sufficient go-arounds with their tech editor in order to meet the schedule. Our standard tech editor contract gives a tech editor 7 days to review a chapter and return it (yet another reason for authors to keep chapters short – so that their tech editor can turn them around quickly!)

How about a practical example? The date I'm interested in for a specific chapter is the date the author gets it to me after all tech editing and author review has been done, and so it's ready for copy editing. Suppose it takes an author a week to do a chapter, then it takes the tech editor a week to review it, and then three days for the author to review what he's commented on, and then three more days for the tech editor to review the changes that the author has made based on the tech editor’s comments, and then a couple of days for the author to review the tech editor’s second review, and send it in to me.

So if the author started on the 1st, it'd go to tech edit on the 8th, back to the author on the 15th, back to tech edit on the 18th, to the author on the 21st, and, finally, to me on the 23rd. Yeah, that sounds like a lot of back and forth time for a single chapter, but remember that chapters are done in parallel, not serial. So the author could be doing an original draft of Chapter 5, reviewing tech edits of Chapter 3, and thinking about pieces that are going to go in Chapter 6. At the same time, tech edit is reviewing Chapter 2 for the second time, reviewing Chapter 4 for the first time. And copy edit is working on Chapter 1, which has already been submitted. That sounds like a lot of work, but, really, it’s not. The reviews usually go by very quickly.

In the above scenario, the date I'm interested in, and will hold the author to, is the 23rd. So while working up a schedule, an author will want to, er, pad their schedule so that they can meet the 23rd date to me. What successful authors often do is (1) get a couple of chapters in the bank (before they're really due), (2) try to stay ahead in case of unexpected interruptions (which always occur), and (3) build in some time to account for sickness, bad weeks at work, vacation, major rewrites based on feedback from tech edit, etc.

If this is the author’s first book with HWP, they’ll likely want to send drafts of the first few chapters by me (even before they go to tech edit.) I won't review them word for word as much as for general approach and style, as well as how the author is organizing their thoughts and such, although if I see anything glaring I’ll probably make notes right in the document.

If you haven’t sensed this yet, it’s probably pointless to mention it now, but I will just to make it explicit. My job here is to help the author and tech editor produce a great book. The only reason I’ve been harping on the schedule so much is that we make commitments to customers and our distributor based on the schedule that the author provides me, and if the book is late, they get annoyed, and we miss chances for promotions and other marketing opportunities. Our distributor, in particular, makes commitments to their customers based on the schedule we provide them. If we're late, they look bad to their customers, a situation we will not tolerate.

When push comes to shove, a great book delivered late will always take precedence over a mediocre one pushed out on time. There are financial hits when a book is late, and the author shares those hits with the publisher, but in the long run, a great book delivered late will still out-earn a mediocre book delivered too early.

Back to Top

Help  |   Contact Us  |   Legal  |   Privacy  |   Copyright  |   Join Our Mailing List