a comment and response from my blog entry announcing the release of the Rails Cookbook:
by Leonard Richardson on 27 Jan 01:22
Rob, congratulations!
Everyone else: from my experience O’Reilly is still getting used to the
PDF thing.
@Leonard: Thanks very much. Yeah, you’re right but as they say, real change
comes from within. That said, having the non-Safari PDF pub two weeks after the print
version (down from six) may have taken some fireworks out of the release party,
but it isn’t really that long to wait–even in Rails time.
In addition to PDF releases, other progress O’Reilly made was towards a 100%
XML-based editorial and production process. Having the book constantly in
DocBook allowed me to incorporate contributed content easily and to build Ruby
tools to manipulate that content. DocBook also allowed me to easily update the
book for Rails 1.2 late in the production process.
In reality, O’Reilly gets a whole different set of problems then some of
their smaller publishing partners, like the Prags. One of those problems is how
to publish the large volume of titles they offer, with consistently high
quality. To do this they have to have more cooks in the kitchen (authors,
editors, etc…) and that makes adapting to new processes more difficult, but
definitly not impossible.
The pattern here is that our media is getting richer and PDFs are just a first step in that direction.
The future is open.
Rob
Agreed on the Docbook. It was a pain to learn at first but it's paying off. The REST book is going to be a lot easier to edit than the Ruby Cookbook was.
Yup, DocBook is great stuff. I'm writing my JavaCC book using DocBook and all the code samples and output are created and inserted when the book is generated; works out really nicely. I use FOP for rough drafts and Altsoft's XML2PDF for production. Good times indeed.
Copy/paste content into Open Office editor. Hit "Generate PDF" button. Voila! :-P
@Daniel Berger: Heh. :) Generating a good PDF is a whole different story. The Prags have great PDF's; interlinked, colorized example code, etc. Try making OpenOffice or FOP do that. We don't use FOP, for example, becuase of a number of things that it just doesn't do for us.
One of those problems is how
to publish the large volume of titles they offer, with consistently high
quality.
What makes it possible for us that that we started with a single, unified system, and we kept with it. We have no problem with volume of titles, because each is the same, and the whole process is automated. It takes a few seconds to push a new PDF.
@Dave Thomas: I really appreciate how your system works. In fact, based on what Andy has shown me, I wish I could have used it for my book. What I was trying to articulate with the word "volume" is that we have many different types of books. Take our Head First series for example. I'm pretty sure that XML wouldn't fly for anyone putting those books together. Same with our Photography books. Also, we have many authors who really prefer to work in Word. Tim's stance has always been to accept an author's content on a napkin if that's how they prefer to work. Admittedly, this all complicates our production pipeline, but it has evolved out of necessity and it has worked really well for a very long time (26 years!).
Rob: I couldn't agree more, and as we branch out into different styles of book, we'll face similar challenges. But, as we do so, we're going to try to keep the same underlying principles intact. That's where we part with Tim: we like to think that our systems bring extra value to authors and, in exchange, authors will agree to use the systems. So far, that's worked out OK, even though we've had to pass on a few hold-out Word users... :)
O'Reilly is way ahead of the curve.
Word ain't so bad, honestly. I can't imagine copy editing in DocBook.