Bookmarks/Annotation import and epubcfi

[Randrewy]

Hello!
I'm currently working on a script to save all my bookmarks from a PocketBook reader to calibre database.

And I'm kinda stuck on getting 100% correct `start_cfi` and `end_cfi` values.
As far I understood calibre uses something different from EPUB Canonical Fragment Identifiers 1.1 as described here https://w3c.github.io/epub-specs/epub33/epubcfi/

Is it intended or a bug, or my understanding of epubcfi specification is incorrect? I think I have kinda working conversion algorithm but it's a little bit arcane and I'm afraid it will silently break at some annotations, and I dont have a way to test it beforehand.

[kovidgoyal]

calibre's epubcfi support was added long before that spec existed, still the basic design is similar. What's tripping you up?

[Randrewy]

calibre's epubcfi support was added long before that spec existed

Ah, I see. Ok, so currently my algorithm is:
for example, given this identifier "#epubcfi(/6/68!/4/2/2/152/1:160)"

1. remove `/6`
2. remove `/68!, convertt it (x/2 -1) to 33 and store as `spine_index`
3. add extra `/2` to the begining
4. at this point i think result is what I need, though sometimes offsets (:160) missmatch, I'm still investigating this part, but I think the issue is because book on reader had another structure (the book itself is deleted though I can link it to the one in calibre library using some metadata)

Btw, looked at the code and now I'm almost sure it is correct algo. Another question is, are there any plans to support epubcfi? I think I could help with that, but I'm very new to calibre source code

[kovidgoyal]

No plans. I know of no use for epubcfi() as defined in that spec.

Your source epubcfi() is from a PocketBook, I assume. What's the add extra /2 at the beginning for? And yes epubcfis() absolutely will not match if the structure of the books is different.

[Randrewy]

I know of no use for epubcfi() as defined in that spec.

Why no? It is just a standart to do the same thing calibre cfi is doing - to reference location in the book. The only reason I'm asking, is to use just the same epubcfi as my reader provides, without conversions. But having an algo to convert one to another is absolutely OK and suits my goals.

What's the add extra /2 at the beginning for?

I believe it stands for "entering root node of a xml chapter file".
So first we go to a file defined by spine_index, then /2 to "enter" that docoment, and the rest of the path is the same both in standart epubcfi and calibre cfi.

[kovidgoyal]

Originally Posted by Randrewy

Why no? It is just a standart to do the same thing calibre cfi is doing - to reference location in the book. The only reason I'm asking, is to use just the same epubcfi as my reader provides, without conversions. But having an algo to convert one to another is absolutely OK and suits my goals.

Because calibre already has a perfectly good standard for this. It's own.

I believe it stands for "entering root node of a xml chapter file".
So first we go to a file defined by spine_index, then /2 to "enter" that docoment, and the rest of the path is the same both in standart epubcfi and calibre cfi.

But that should be present in the source CFI as well, so there should be no need to add it.

[Randrewy]

But that should be present in the source CFI as well, so there should be no need to add it.

If I read specs correctly epubcfi indirections points into root element right away, there is no need to enter it with `/2`.

This is from specification:

If a step, or a sequence of steps, points to an element that references another document <...> The following expression is then resolved from the root element of the referenced XML document, or from the targeted XML fragment (when specified).

Because calibre already has a perfectly good standard for this. It's own.

Ok, I got you, I now have a conversion algorithm, it suits my needs.