(Fourth post in a series that begins here.)
The goal of doing the clean docx to epub conversion with Calibre, which is the topic of this series of posts, was to have an epub file worthy of submitting to the iBooks marketplace. Apple’s validator is known to be the pickiest of all the four main marketplaces (Amazon Kindle, Barnes & Noble Nook, Apple iBooks, and Google Play).
We’ve done all our ebook publishing, to date, in the Kindle and Nook marketplaces only. But Bret and I put our heads together recently and concluded we should start selectively publishing in the iBooks and Play marketplaces also.
It’s hard to come by market share numbers for the different ebook marketplaces. The last credible numbers I saw still had Kindle way ahead in book downloads and iBooks with a miserable 5% share. But this is a market where the tide can turn in almost an instant.
I’ve been seeing a lot of reports that the sales of dedicated reader devices (Kindle, Nook) is going down as the share of all-purpose tablets is going up. If true, much of the future growth in ebook sales will be to people using all-purpose tablets not dedicated readers.
The Kindle and Nook Reader apps are free and available for almost any device from desktop to phone. So you can, already, read your ebooks from Amazon or B&N on your iPad or Android tablet without ever having to own a Kindle or a Nook. But Bret believes that the users of iThingies, in particular, are eventually going to want an iBuying experience for their ebooks. And I’m inclined to think he may be right. So I want to make sure the books we publish are in the right boat if the download tide does turn.
I’m not trying, in this post, to give you any sort of tutorial on how to set up an iBooks account or use ITunes Producer to do the actual publishing. That is way above my pay grade. I mainly just want to wrap up with a declaration of victory:
True to it’s promise, Calibre’s new docx to epub conversion feature is capable of generating an ebook even Apple will accept!
And to make a couple of observations about how the iBooks publication process differs from the Kindle and Nook processes.
The oddest thing about setting up an iBooks account is how often Apple will suggest you NOT complete the process. “Woudn’t you really like to work with a book aggregator?” the online forms ask you over and over. Unlike Amazon and B&N, Apple is clearly not encouraging Every Writer to be his or her own ebook publisher.
The oddest thing about actually publishing an iBook is that the work is NOT done through your browser but rather through an app you have to download and install, called iTunes Producer. And, yes, Producer only works on an OsX box. So you need to have a Mac in order to publish an iBook. Even iTunes Connect, the process for publishing an iPhone app, works via the browser. But not Producer. On the other hand, you do need a Mac to build the iPhone app itself, so maybe that is the more appropriate comparison. The tool is called “producer” after all, not “publisher.”
But, say you are at the stage of being curious about, not committed to, iBook publishing. Say you aren’t quite at the point of letting iBooks publication finally provide the justification for you getting that MacBook of your dreams. Can you at least get a sense of how your epub file would fare against that iBooks validator I keep mentioning?
Yes. You can preview how iTunes Producer will validate your epub file(s).
The validator used by Producer is said to be the same as the one that the International Digital Publisher Forum (IDPF) makes available, for free, online at: http://validator.idpf.org/
Like all such open source tools, though, this validator is available in multiple versions and each version has many different runtime options. We know for certain that Producer’s validator is either a different version than the one available online or is set up to run with different options. Runaway’s epub passed the IDPF validator and failed Apple’s.
The IDPF validator is free and easy to use, though. So I recommend you make sure your book(s) can pass it before you go through the whole hassle of creating an Apple ID account, installing iBooks Producer, ya da ya da.
Hold on to your hat the first time you submit your epub to the online IDPF validator, though. You’re likely to be surprised by how much it complains about.
Runaway reported just a single error. Still, that one problem took a while to diagnose and resolve. (The problem came not from the book conversion process itself but from the Calibre viewer contaminating the file when we previewed it. Gory details here if you are interested.)
Our much more complicated ERG2012: Quick Lookup epub reported thousands of errors on its first pass through the online validator. Criminy. Yet we’ve had no trouble having the book accepted by the other marketplaces. And both the Kindle .mobi version and as the .epub Nook version look and work great on their dedicated readers and within their appropriate Reader apps. How could the epub harbor thousands of errors?
The number of errors would have been a lot scarier if I didn’t know two things:
- The ERG2012:QL html source document is generated by a program from a set of large data files. One small error in the code, such as not writing out a </tr> tag at the end of a table row, can easily result in a couple thousand errors in the html and, hence, the epub.
- Errors in validation, like errors in compilation, can compound. Confuse the validator early in the file and almost every line after that may be reported as an error.
We’re still in the process of scrubbing and doing a bit of re-plumbing for the ERG; the iBooks victory dance for it is still a ways off.
In the meantime, after fixing our one error, Runaway was accepted for upload:
Then it sat around “in review” for a while but, finally, went on sale:
That’s one small huzzah for the author and one large huzzah for her daughter.