|
A couple of thoughts on all this:
1) The issue with EPUB-3 goes beyond whether the .epub in question has DRM or not. Correct me if I'm wrong, but currently the only e-ink epub renderer that has even close to decent EPUB-3 support is ACCESS.
So Kobo gets a book. The metadata states the book is DRM-free EPUB-3. What's Kobo supposed to do with this book?
Well, as has been mentioned previously in this thread, most EPUB-3 books are mislabeled. Kobo could just put up the download link. But what happens when the book *isn't* mislabeled?
Sure, the customer in question could be using a third party app on a tablet, or some program on a PC that will read EPUB-3. However, they could also be part of the not-insignificant Sony Reader customer base that Kobo just acquired. Or users of some other RMSDK based EPUB-2 reader. How do you calculate the odds? You want to maximize the percentage of the customer base that the product will "just work" for.
Kobo appears to have taken the conservative position of not offering EPUB-3 for download/sideload. A perfectly legitimate position, albeit one that's inconvenient for those of us around here who tend more towards the power-user side of the scale.
Now ideally, Kobo would have the infrastructure in place to validate every book they retail. However, I have no idea what that infrastructure would cost. In the case of DRM'ed books, I don't even know if it's all that feasible, as IIRC Kobo doesn't actually have the book files in that case.
2) In regards to the picture zooming issue: Isn't the problem on the RMSDK side? Kobos use RMSDK for sideloaded epubs (unless renamed or converted) and RMSDK doesn't zoom pictures. Unless I'm wrong?
If picture zoom is a RMSDK feature that Kobo hasn't implemented, then yes, blame Kobo for not fully exploiting the kit. If it's not, then I fail to see why Kobo should be blamed for implementing features in ACCESS that RMSDK lacks. Especially when you consider that the vast majority of their customer base likely never touches the RMSDK side at all.
|