Simplifying eBook Creation
UPDATE, May 10, 2011:
The latest news about eBookBurn.com can be found here.
That audience was mostly developers or people otherwise technically-oriented, and while there were a decent amount of well-informed questions, it was clear that creating an ePub from scratch was a lot of work, with few good (read: simple) tools.
Fast-forward to last month, when I released eBookBurn.com, an online eBook creator composed of Xinha on the frontend, fused with a more sophisticated version of the ePub generator described in the IBM tutorial.
The initial response was terrific, and I even got an early review at the Digital Reader blog.
Over the past week, I got a chance to address common feedback with an update which I released today. Here were the major points:
- Cover Image Sizing
- Importing from existing docs
The first go-round on pricing was based on the idea that if you hire a consultant to prepare a specification-valid ePub (and validity is important, since you cannot sell in Apple’s iBookstore otherwise, for example), it will cost upwards of $500 per book. So, in that context, a create-all-the-books-you-want model for a given amount of time made sense.
Many people felt that was too high for self-serve, though, and it was a good point: while I make an effort to answer support emails, there’s no guarantee that I’m able and willing to address every customization request.
So the new pricing reflects that, and there’s also a three day initial period where use is free.
Until today, your book cover image had to be exactly 590 pixels wide by 750 pixels tall. Any variation got you rejected.
Now, it’s more of a suggestion, since the new release simply scales your image to the right size automatically.
This is important for a few reasons: it’s a better user experience, and the 590×750 size is based on current standards, which will change over time as device resolution improves, etc.
In the first release, you had to type everything from scratch, or cut-and-paste from another document.
While that option is still there, many people wanted to be able to upload a non-eBook format document, and have the conversion done automatically.
PDF was by far the most requested, followed (weakly) by MS Word.
PDF is evil. Although it is called a PDF “document”, it’s nothing like Word or HTML document. PDF is more like a graphic representation. PDF contents are just a bunch of instructions that tell how to place the stuff at each exact position on a display or paper. In most cases, it has no logical structure such as sentences or paragraphs and it cannot adapt itself when the paper size changes. PDFMiner attempts to reconstruct some of those structures by guessing from its positioning, but there’s nothing guaranteed to work. Ugly, I know.
The results are decent (if I do say so myself), but a lot depends on what kinds of pdfs are uploaded: essays, whitepapers, and other mostly-text docs come out ok, with some editing needed. Brochures, slides, forms, and other works with more intricate visual formatting require much more editing.
But in contrast to other conversion tools which simply take static jpeg or png snapshots of each page (I’m looking at you, calibre), the full text is parsed and returned as text, which means it can be edited.
There’s still no support for uploading and converting MS Word documents, partially because of how few people asked for it (especially relative to PDF), but mostly because of the huge pain in the neck it is.
One option is to ask people to save as filtered HTML first, before uploading, but it’s not the best solution, so I’ll be considering ways to address that.
I’ve also noticed that cutting and pasting from Word docs, which is the only alternative in the meantime, introduces funky Microsoft-specific namespaces which break validation, so I need to come up with a solution for that as well.