Could we use the TextQuoteSelector as the "lingua franca" of selectors?

[llemeurfr]

We need a selector that is a MUST for every implementation of the Annotation model. If not, interoperability will be totally broken.

Readium developers have either TextQuoteSelector and DomRange Selector as their preferred locator.

The big issue with TextQuoteSelector is that it contains a segment of the text of a publication. If the publication is protected by LCP, because this clear text can be quite large, we have an issue (even if other vendor like Amazon don't seem to care about too much about this).

A potential solution could be to limit the size of the text contained in the exact, prefix and suffix properties. For instance with a limit to 10 characters + "..." + 10 characters for exact, and at most 10 characters for prefix and suffix. With such constraints, the managers of LCP could admit that it does not harm the protection given by the DRM.

Is it something that could technically be efficient for locating annotations?

[HadrienGardeur]

We can't use a TextQuoteSelector with audiobooks or Divina.

Are you limiting the scope to primarily text-based publications? Because even for those, a user could annotate an image, audio or video resource.

If the publication is protected by LCP, because this clear text can be quite large, we have an issue (even if other vendor like Amazon don't seem to care about too much about this).

In trade, no one seems to care about that, this goes well beyond Amazon.
In academic publishing, publishers are usually a little more cautious, but that's also the market where fully contextualized annotations are the most useful.

[llemeurfr]

In https://github.com/readium/annotations?tab=readme-ov-file#122-selector we see that the TextQuoteSelector is only used in text-based publications. audiobooks and Divina have other required or possible selectors.

[mickael-menu]

The shorter the snippet, the more false positives we might get while looking for occurrences. I don't know what's the minimum snippet length to be safe.

If we go down this way, I would separate into new properties exactStart and exactEnd instead of adding ... inside exact. Alternatively, make exact optional and just keep longer prefix and suffix.

Implementing this solution is more complex but doable. We will need to match two snippets instead of one and then merge the returned DOM ranges.

---

But I would really avoid censoring the text snippet unless it's really a deal breaker:

• Like you mentioned, other vendors don't do that.
• It would prevent displaying the annotations on their own, which would be convenient to export your notes to process them in a reference software or note editor.
• Nowadays you can't protect against copy anyways. On MacOS it's as easy as taking a screenshot and then using Preview to select the content using OCR. On Android it's even easier as you don't even need to take a screenshot.

Screen.Recording.2024-09-16.at.18.17.40.mov

Maybe an alternative could be to limit the length of the annotation to a reasonable size?

[HadrienGardeur]

Nowadays you can't protect against copy anyways. On MacOS it's as easy as taking a screenshot and then using Preview to select the content using OCR. On Android it's even easier as you don't even need to take a screenshot.

That's right and these features are now becoming available in Chrome desktop as well, with a Lens action now available in the address bar for any website.

On Android, users can:

• use the app switcher, from which they can easily select and copy text or images
• use "Circle to search" while in an app to select whatever text they'd like to copy
• take a screenshot then use "Lens" and its text feature
• or even get the text automatically extracted and indexed if they're using a recent Pixel device with the Pixel Screenshots app

On iOS and macOS this is handled through the Live Text feature.

This even works on FXL publications where the text is actually an image, since all of these features are using OCR to detect and extract text. It's more powerful than any text selection feature in a reading app.

Actually, we might want to look into these API to power some of our accessibility features.

I think we've actually reached a point where the copy limitation cannot be enforced and extending this limitation to annotations was already a bit of a stretch and inconsistent with what other vendors are doing.

[llemeurfr]

Note: the best practices for locators should be kept in sync with the annotations spec after we reach a consensus on the required locator for sharing purpose.

https://readium.org/architecture/models/locators/best-practices/format.html