Dealing with errata

To start a new edition, the first thing that we want to do is fix the old edition. Fortunately, O’Reilly Media has a nice system for reporting and confirming errata. Many times, minor fixes such as typos can even show up in subsequent printings of the same edition. Bigger changes have to wait for a new edition.

To start work on the sixth edition, I pulled up the list of confirmed errata. The list might look long, but for an author it seems short. There are so many things that can go wrong in a book that it’s surprising that more things don’t go wrong. The list is really even shorter than it looks because many of the reports are actually duplicates; as the reports come in, we don’t remember which ones we’ve previously confirmed.

I was expecting to spend most of the day applying the changes, but I discovered that I’d already made most of the fixes. We’ve been tracking Learning Perl in source control for awhile (first in subversion but now git), and I usually make fixes as they come in. It’s easier to do it that way since I already have to look at the sources to confirm the errata.

I don’t just look in the printed book because the ink on the page is a couple steps removed from the original material. I want to see if it’s something that I messed up (and it usually is) or if something changed in the printing. O’Reilly actually has a nice system for that now: all the sources go into a DocBook format which I can then immediately use to build the (mostly) ultimate form. By adding a few keywords to the commit message, O’Reily’s special post-commit hooks take over to format the book. At any time that I like, I’m 15 minutes away from seeing what the book looks like, just as a PDF file instead of a dead tree. That means that I should also catch errors before they make it to the printer.

So, that’s off my to do list sooner than I expected. The next step is to figure out where the new material is going to go.