More on TechnologyTell: Gadget News | Apple News
German publishers botching ePub, at least for the Sony Reader? And that’s just one problem.
April 6, 2009 | 6:26 am
|
By David Rothman
“We’re a bit heavy-hearted to report of plenty of unhappy German-speaking users complaining about the sub-optimal quality of ePub titles they’ve purchased. One cannot help but believe that those book editors in charge were lacking important technical information regarding the current limitations of the Sony Reader. For instance, some simply ignored the size limitation of 300Kb per XML/HTML chunk. Without splitting large files into these smaller chunks, the converted e-book won’t work properly on the Sony Reader. We’ve heard of at least one e-book that has been sold like this.” – Mtravellerh in MobileRead.
The TeleRead take: This is hardly a German-only problem. Time for Sony to launch an aggressive outreach effort to educate publishers? Then again, as Steve Jordan has pointed out, should it really be necessary to adjust ePub files for a particular device?
Other ePub creation issues issues
All over the planet, the issue isn’t just file size. It’s also the complexity of creating ePub documents. Granted, some possibilities are emerging, but the IDPF has a lot of work to do in this area if it wants to serve all publishers, large and small. I continue to believe that the IDPF needs to be financing and promoting free creation tools and readers alike—software with license terms that would not prevent private companies from picking up the better features. The existence of the same software would help encourage genuine adherence to standards.
IBM: Possible IDPF angel?
While the IDPF’s resources are limited , wouldn’t it be logical for a company such as IBM—which has thrived with open source—to offer the financial help that publishers have refused to do? Or maybe fund development of the open tools directly? I can also see a role for private foundations such as MacArthur. The involvement of IBM and private foundations would be one way to deal with the very real concerns that Adobe—a leading provider of ePub-related software—exercises too much influence over the IDPF. For now, I suggest that the IDPF spend a few hours going through Twitter messages to grasp the full extent of the problem.
Just as much as ever, I strongly support ePub, the idea of an alternative to eBabel. I also strongly support the idea that the IDPF needs to do much more to improve both the standard and its implementation, as well as work toward a logo for nonDRMed ePub.
Related: ePubWriter for small publishers and self publishers? A TeleRead challenge to the open source community—plus Azardi is now in Release 2.
Technorati Tags: German publishers,German pubishing
|
Previous
SUBSCRIBE TO RSS
Comments:
Seriously? You are blaming the publishers for actually following the *spec*?
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
But, John, let’s be practical. The Sony owners are a huge market right now, and anyway, I’ve already noted you point above, via my reference to Steve’s excellent point.
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
Sony’s Reader isn’t the only epub displayer that can’t handle big chunks–most of them need chapters broken out. Yes, it’s a bit of a pain, but it’s not prohibitive. (Seems like the message for publishers here is ‘test your products before releasing.’)
What’s up that the Sony Reader has this limitation? Is this an OS-level thing? It is Sony being proprietary? Steve’s point is correct: we should be able to do *one ePub file for all*.
Should I start yelling at Sony?
One other thing: the ECTACO jetBook just added ePub capability. Non-DRMed ePub. I’ve emailed them to ask what rendering engine they’re using. I’m very interested to see what the jetBook does with ePub.
David knows full well that the reference implementation for epub (Adobe Digitial Editions) does not follow the epub spec. ADE needs files to be split up into 300k chunks.
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
“As well, the spec itself should be modified to take the real world into account, now that the world has been using the spec.”
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.
I can attest to the fact that breaking chapters into individual ePub sections isn’t rocket science… it is do-able. However, the ADE/Sony Reader’s limitation is more than likely a programming limitation, and can (and should) be changed.
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.
Mike Cane: “What’s up that the Sony Reader has this limitation? Is this an OS-level thing? It is Sony being proprietary?”
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.