Quote:
Originally Posted by Sharkus
Exactly. If it's only unique for one app / platform it's somewhat useless to say the least.
That would be the first step, figuring out what to use to get an id that can be used across multiple platforms.
There are other challenges though, for example, how to specify the position in the book? the chapter level, yes, that could be done simply by just getting the path to the current file being read, but what about the position in that file. I know what is done for downloaded books, but that's part of the processing when the book is added to the system, and so it's not something the app / device does, so how to go about doing that?
|
The firmware already has the location that could be transferred. The reading position is an identifier for the book plus the location inside the book. The location inside the book for sideloaded epubs uses the Adobe RMSDK method. This is basically the path of the internal file being read plus a walk of the HTML inside the file counting tags and the levels of nesting. Plus the number of characters within the lowest tag. An example is:
Code:
OEBPS/Text/Chapter08.xhtml#point(/1/4/2/1:0)
I can already transfer this between my devices using my calibre plugin. This works as long as it is the same epub on both devices. And from a quick look at the database on a Sony, it wouldn't be to hard to move this to that device.
The way Kobo does this for kepubs is pretty horrible. Adding all the spans for the ids is just ripe for breakage somewhere along the way. It is no more robust than the above. I think it would have been better for Kobo to use the RMSDK method, or, better still, the method that is part of the epub3 standard.