It’s a little complicated, but it’s essentially a technical limitation of the ePub format itself.

One limitation, and the one easiest to fix, is due to the use of HTML. People, and thus HTML renderers, like to load the entire XML document at once (the DOM model) because it allows you to do some cool things (the dynamic Javascript pages you see these days). That’s simply not possible on an limited, embedded device.

Note, however, that eBooks don’t require, or support, these dynamic features and older eBook formats weren’t XML-like. So, the book renderer can stream the XML, there is no limit, and everyone is happier (note that this is a bit simplified, but not by much).

Another problem is that neither the ZIP format nor HTML are suited to random access. Whenever you process the book you have to either move forward or start from the beginning of a file. This means that clicking a link or a jumping to a page requiring rendering the entire document up to the point you are going (which is, needless to say, rather slow).

So the experience isn’t going to be great without chunking the book (which is fairly easy) or changing formats (which isn’t going to happen). The software authors could make the reading experience acceptable without chunking, but it requires being clever (where clever often involves the risk for being error-prone and requiring slightly more development money).

I sort of wish there was a $300 open source eBook reader readily available just so I could try to demonstrate my own cleverness.

Fortunately, my e-books are already broken up, so they display on the Sony okay. But if it were not the case… say, if Sony was telling me I had to create one big file to work on their readers… I’d pass. Proprietary versions of common formats aren’t going to help eBabel, and I wouldn’t support that.

John, I could not agree with you more on the point above. The idea of requiring files to be broken into smaller chunks looks promising. Oh, and it’s one more argument for better creation tools–so that things can happen with minimal hassles for publishers. I think it would be cool if you compiled a list of the ten things that most annoy you about the current spec, so that the people responsible for it can learn. I’m pro-ePub but not “pro-ePub as is.”

Thanks,
David

P.S. The “ten most annoying things” invitation is for others as well. I’m thinking from an end-user perspective. Perhaps that viewpoint could be used in coming up with the list.

The only way this is Sony’s fault is that Sony chose to use ADE rather than some other even less mature epub rendering engine.

The epub spec is not “realistic” enough to specify that files should be broken into chunks to work on small devices.

So it is possible to make a completely “correct” epub that is completely useless.

The fault lies not with authors, publishers or Sony. the fault lies in allowing Adobe to claim that ADE is epub compliant. As well, the spec itself should be modified to take the real world into account, now that the world has been using the spec.

jmurphy

Should I start yelling at Sony?

If Sony can address the 300K issue, great. But what about people who’ve already bought Readers?

I myself happen to own a PRS-505. So, while I won’t exactly be buying German ePub books tomorrow, this issue is still of interest to me.

Thanks,
David

The epub spec says nothing about a 300k limit, does it?

So how is this the fault of anyone who accurately follows the spec?

jmurphy