Converting between Xpointer and CFI

[jmt-gh]

Hi! I've been working on a side project that is looking to emulate some of the functionality of Amazon's "Whipser Sync for Voice" (syncing progress between audible audiobooks and kindle ebooks).

Currently, I'm able to arbitrarily update the progress/location of an ebook through a self hosted instance of koreader-sync and KOReader. The next step I'm working through is writing a service that parses through an epub for a given substring, and then uses koreader-sync to update the progress based on the location of that text.

The problem I'm running in to is all of the libraries I've found for interacting with epub all return text location as CFI, while KOReader is using Xpointer. I was wondering if anyone had any guidance on ways to convert between the two of these? Or if there is a way to get KOReader to support CFI through koreader-sync that I've possibly missed? Or even better yet, if anyone knows of a library / way to get an Xpointer location directly from an epub in some sort of automatable way?

[Frenzie]

What's CFI?

[jmt-gh]

Hey @Frenzie! It's the format the epub standard lays out as the way to reference arbitrary locations within an epub

http://idpf.org/epub/linking/cfi/#sec-overview

[poire-z]

Nope, there is no existing support to anything CFI in KOReader and its EPUB engine (crengine).
crengine is the thing that work with xpointers, and its xpointer stuff is somehow proprietary/homemade (no external spec).

About CFI: http://idpf.org/epub/linking/cfi/ (dunno if it's the most recent spec)

And I don't even think you can convert from outside a xpointer to CFI (because it has indices by elements, body/div[1] and body[p[1] could be in any order, so you can't say if the P is before the DIV or not, to convert them to indices...)

You would need to add support for CFI in crengine itself (C++ code): from the DOM node and the DOM, I guess it would be possible to return a simple CFI with just indices. The reverse (any form/kind of CFI) to node might be harder...
But this would need to read and understand this ugly spec and some interest :)

[poire-z]

For reference, the crengine code about xpointer string conversion to/from nodes.
https://github.com/koreader/crengine/blob/de482f93541f50509ba1d76fd3145ccdaf37e60a/crengine/include/lvtinydom.h#L1610-L1622
https://github.com/koreader/crengine/blob/de482f93541f50509ba1d76fd3145ccdaf37e60a/crengine/include/lvtinydom.h#L2474-L2477
https://github.com/koreader/crengine/blob/de482f93541f50509ba1d76fd3145ccdaf37e60a/crengine/src/lvtinydom.cpp#L9894-L10195

[jmt-gh]

Thanks @poire-z ! Is crengine's xpointer implementation pretty bog standard? i.e If I could find an XML parsing library that returns in xpointer, and be able to use that? Or are there crengine-isms that would need to be accounted for?

[poire-z]

Nope, it's not standard at all (to my knowledge): its xpointer stuff is somehow proprietary/homemade (no external spec).
So, I don't think any library knows about xpointer, and even could help - and what I meant above with the DIV/P ordering example is that, outside of crengine and without the real document parsed and its DOM available, you can't really get a deterministic reference to the node :/