Thread: Aura HD Kobo Reader and Bookstore for non-drm or drm-removable books?
View Single Post
Old 03-19-2015, 08:32 PM   #34
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by BryanK View Post
I had always assumed that the chapter position was calculated off of the current 1024-character page.

I haven't looked closely at the files of a DRM-stripped kepub. So there are no modifications to the kepub itself to support things like annotations or dictionary lookup? If not (which seems to be the case since you can just rename an epub), then as you say, the only reason DRM-free epubs couldn't be rendered by either engine is the extra step in identifying which epub file has DRM and which doesn't.
The position in an epub is recorded as a walk of the tags in the current internal file plus a character offset within the current tag. A Kepub is different in that each sentence is wrapped in a span with a unique id. The position is the id of the span plus a character offset within the span.

The chapter graphs for kepubs are appear to be based on the word or character count in the chapter. At least, I can see a difference in height of a three page chapters with a couple of lines on the last page against a full third page. I assume the height of the current position is based on the same thing, but it might be just divide by the number of pages. The proof of which way would be to create a chapter with several pages of single word per line and one page packed full of text.

A kepub is a valid epub. The spans added for navigation/bookmarking are annoying but work. I keep hoping Kobo will drop them or at least use another method if they don't exist in the book. The do have other requirements, but they are tightening of the epub specs rather than things that break them as an epub. And they use a different DRM which means a different DRM decoder.

The only other wrinkle to this is that a kepub can be based on an epub3. The ACCESS (or whatever it is called now) renderer is an epub3 renderer. It seems to do a good job with epub3 features that are practical for an e-ink ereader. If epub3 kepub doesn't use any specific epub3 features, the version of RMSDK used by Kobo will probably will probably open it OK. But, if epub3 features are used, there will be problems.
davidfor is offline   Reply With Quote