Denis Papathanasiou

Last year, I presented a talk at BarCampNYC5 on "How to Create an eBook".

I spent most of the talk on ePub, and how to generate ePub files programmatically.

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.

Even Adobe’s InDesign, which is used by most professionals, requires significant manual reworking.

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.

I announced it on Hacker News, reddit, and MobileRead.

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:

1. Pricing

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.

2. Cover Image Sizing

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.

3. Importing from existing docs

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.

Even though PDF is a notoriously difficult format to parse into text, I have been experimenting with using the PDFMiner API, so I thought to try it here, despite Yusuke Shinyama’s warning:

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.

In theory, importing from Word’s docx format should be trivial, since it’s xhtml under the hood, which is just what ePub requires, but Microsoft added a few surprises.

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.

Tags: E-Books, eBookBurn.com, ebooks

This entry was posted on Thursday, January 6th, 2011 at 10:45 am and is filed under Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.