Comment by nicw | Hacker News Reader

Comment by nicw | Hacker News Reader

There is definitely a misnomer that ebook creation is easy, especially as so many creation tools seem to output to .EPUB. The key isn't creating an EPUB, it's creating a good-looking EPUB.

This stuff is hard and I totally understand your pain - I'm the digital product manager over at Blurb.com (ebook!). We're primarily focused on fixed-layout epubs which ensures that the picture you laid next to the text will always stay in the same place. Reflowable epubs are technologically easier to create but the output can vary so much that it makes the author look sloppy at times. Not cool.

You can create a Blurb book and then convert it to an ebook for $1.99. We create them to Apple's strict epub standards so you can even submit it to their iBookstore. No DRM. :) (http://blurb.com)

Looking forward, I think we are going to see a larger focus on fixed-layout ebooks in the future as more tablets are created (Kindle Fire, iPad) and authors see the limitations of reflowable ebooks. I'm not knocking reflowable ebooks, but just writing a book in itself is a huge undertaking (congratulations!); trying to maintain formatting and a clean layout afterwards feels like you're being punished.

As to anyone else who has gone through ebook creation/conversion with Blurb (or elsewhere), feel free to send me a note or comment with your questions. It's rare that a HN thread directly relates to my work :)

- Nic.

I can totally understand why this would be hard once, I'm trying to understand how this would be hard in repetition.

Lets say you do the work of creating an EPUB formatter that works to your satisfaction, then is it like a pipeline where you can feed new material in and get books out repeatedly, or do you have to tweak it for each book?

It's a little bit of both. What really happens is that you're looking at a moving target in terms of both inputs and outputs. Think of this like the early browser wars, where even a standard chunk of HTML could look different.

You can create an EPUB formatter that works to your satisfaction, but you've only coded it to work with that set of books. The next set of books may have different layout requirements, like padding between the text and the images.

Secondly, the epub world is evolving, and the readers that display the epubs all have their own interpretation. EPUB is simply HTML/CSS inside a .zip. e-readers are essentially browsers wrapped in their own chrome.

So, the real trick is to automate as much of the formatting as possible, but then have easy tools for the Author to make the final tweaks.

Ok, lets follow along further.

"It's a little bit of both. What really happens is that you're looking at a moving target in terms of both inputs and outputs."

Can you say more about this, it seems like we have two, perhaps three, targets; Kindle, iPad, and Nook. Together they probably make up over 95% of the e-book 'market' in terms of readers. Also they have a vested interest in making sure that books that look good today, still look good in the future so that publishers won't get stung by having to re-generate books.

Now the original discussion here was about authors who are trying to publish their own e-books. So when you said this:

"Secondly, the epub world is evolving, and the readers that display the epubs all have their own interpretation. EPUB is simply HTML/CSS inside a .zip. e-readers are essentially browsers wrapped in their own chrome."

I sort of tuned it out, while I can certainly see the top three book readers having their own interpretive quirks for EPUB, if, as an author, I get my tool chain which converts my manuscript into an acceptable EPUB on these three platforms, I would expect to be able to re-use that tool chain over and over again. So if I'm writing suspense novels, and my friend Bud gives me the occasional pen and ink illustration, I should be able to create a tool chain which can take my prose, scans of his drawings, and poop out an epub file. Then I sit back and go all Agatha Christy and write 150 detective novels.

Once the pain of getting the tool chain to work, with the caveat that book reader vendors are committed to backwards compatibility, I'm wondering why it would be 'hard' to publish after the first one was done.

Now granted if I went from pulp fiction to coffee table photography books I could see my tool chain being unfit for the task. And I could also see how, as a publisher of many authors it would be a pain in the arse to account for all of their different styles and topics and books and features etc. But if the rules really have changed, and its really 'better' for me to just publish my own books and distribute them through a channel like iTunes or Amazon, once the mechanics of publishing my style of book are over come, why wouldn't they stay over come, at least for me to get several books out using them?

Can you please explain the difference between reflowable and fixed-layout ePubs?

I thought the entire point of using ePub over PDF was so that it would be more adaptable to each reading device and/or reader (e.g. larger font sizes).

A really good explanation is here: http://www.quora.com/Whats-the-difference-between-fixed-widt...

but the tl;dr is: Different needs for different book types. Think of a reflowable epub as a .TXT file and a fixed-layout epub as an HTML file w/CSS. Yes, a .TXT file is indeed reflowable and adaptable for a screen size.

But what if you're writing an instructional book? Or you've made an awesome photo book of your travels? This is where presentation is more important over reflowable. It's important that the images you are referring to in the text are on the same page. Fixed-layout doesn't have to mean exact pixel representations just as most modern-day web pages adapt to user screen size. You can still "reflow" your text into a fixed-layout epub, the creation tool helps make this easy.

At the end of the day, the screen ratio of tablets is fairly similar, and epubs are just HTML + CSS. A fixed-layout epub gives the author the choice of control - they don't have to specify rigid container widths just as much as they don't have to specify a font.

Reply on news.ycombinator.com