Matching a bookmark to the current screen page

[sema95]

I've recently integrated Readium into a personal project and the experience has been great so far!

One area that I still can't wrap my head around is bookmarks. Saving a bookmark and navigating back to it is no issue and the test app has been great to understand the right patterns. However, I want to display a visual indication on the screen if there is a bookmark set. This works well as long as the font size and layout don't change. If they change, I have trouble matching the locator to the screen-page where the bookmark is supposed to be (but which is now different of course, because of font and layout changes).
I already tried a lot of different approaches and so far, I am either losing the visual reference because I am no longer matching the bookmark, or I match it on multiple screen-pages.

I am not entirely familiar with the Readium vocabulary yet, so I hope the description of my problem is not too vague. Any help or information that could steer me in the right direction is much appreciated!

[mickael-menu]

Which strategies did you use to locate the bookmark?

With EPUB and PDF, I think you should be able to compare the bookmark's position with the currentLocator one (locator.locations.position).

[sema95]

Hi @mickael-menu, thanks for the quick reply!

Using the position was my first approach but since one position can span multiple screen-pages, I would have the visual indication for the bookmark across all of them. This is of course the expected behavior but I think it will confuse the user, as they will see it as multiple bookmarks and not one. Ideally, I would anchor the bookmark to the first sentence of a screen-page when it's set, and match it that way (even after font-size or layout changes) but I have trouble figuring out a robust implementation around this.

[mickael-menu]

I see, then you might try the locations.progression and use a small range delta to determine if the bookmark should be visible.

There's no way to use a sentence-based strategy at the moment for this.

Alternatively, you could use the firstVisibleElementLocator() API and add a page margin Decorator to be positioned exactly at the sentence location. Look for this template as an example in the test app:

kotlin-toolkit/test-app/src/main/java/org/readium/r2/testapp/reader/EpubReaderFragment.kt

Line 331 in fecd9b6

private fun pageNumberTemplate(): HtmlDecorationTemplate {

We're still missing a Kotlin guide for decorations but you have some documentation here: https://readium.org/architecture/proposals/008-decorator-api.html

[sema95]

Thanks, I will look into these options. I already tried something similar to the range delta but unfortunately it wasn't very reliable and also lead to multiple representations of the same bookmark. I will try and see how the Decorator works and if it could be an option!

[sema95]

One more thought on this: Is there a way to get the progression of the next screen-page? Because that would solve my issues, I could just match the bookmark with the progression range of the current screen-page and the next one instead of relying on a small range delta.

[mickael-menu]

No but I'm actually working on this now! This should be available in the next version.

[mickael-menu]

In the next version the EPUB navigator delegate will report changes of the viewport object:

https://github.com/readium/swift-toolkit/blob/1c89282c2220841e37cce1a481dee91dd7c54f57/Sources/Navigator/EPUB/EPUBNavigatorViewController.swift#L15-L16

The viewport contains these infos:
https://github.com/readium/swift-toolkit/blob/1c89282c2220841e37cce1a481dee91dd7c54f57/Sources/Navigator/EPUB/EPUBNavigatorViewController.swift#L134-L145

It is a bit complex because you can actually see several reading order resources at the same time on the screen, so the progressions property reports one progression range per visible reading order resource. For your bookmark, you will need to check the reading order index of your locator, for example with publication.readingOrder.firstIndexWithHREF(locator.href).

It's already available in develop. These APIs might still change a bit before the next release, feedback is welcome.