Dave Thomas from the Pragmatic Programmers is mulling whether to make their books available on the Kindle, and encountering many of the same issues we faced here at O’Reilly regarding technical content and the limitations of current ebook devices:
In fact, we’ve had a prototype form of that capability for a while now, but we’ve always held back. Frankly, we didn’t think the devices worked well with our kind of content. Basically, the
.mobiformat used by the Kindle is optimized for books that contain just galleys of text with the occasional heading. Throw in tables, monospaced code listings, sidebars and the like, and things start to get messy.
Dave’s post has sparked a great conversation within the comments, including one from Shelly Powers, whose book Painting the Web was among those included in our pilot program:
I think that providing the package deal that O’Reilly does (with PDF, epub, and mobi), in addition to downloadable code is the way to go. If you sell Kindle books, you definitely need to make both your figures and your source available, separately. For instance, I have my Painting the Web figures in an online gallery and the examples are available at O’Reilly–takes care of a lot of issues related to Kindle. Another approach could be to make available (for no additional cost) a PDF of just the figures, or the figures and code.
Preparing a book for the ebook market may seem like a lot of work, but you have the potential to reach a new audience of book buyers. Buyers used to the internet and having access to immediate information; who may not want to order a book and wait a week for it to arrive, but who will buy a book if it means they can have access to it now. I wouldn’t have considered myself an "impulse buyer" when it comes to books, but I have probably at least a dozen books I bought because the ebook format was cheaper (that’s a key element), and I could get the book _right now_.
On one hand, merely working to replicate a print experience isn’t the right way to exploit the benefits of the new platform; on the other hand, publishers (and as usual, I use that term quite loosely) should be able to expect at least minimal rendering of common elements like tables, along with support for at least the same core 14 fonts available in Acrobat (speaking of fonts, if you’re looking for a laugh check out this mock "font conference").