pdf/html/epub viewer: make text selection boundary configurable

2a18f1
Word/lines are selected using a double or triple click. I use word boundaries almost all the time, resulting in a lot of extra clicks. Ideally the single/double/triple click behaviour would be configurable, e.g. by offering a word-centric mode mapping single/double/triple clicks to word/character/line boundaries, and a character-centric mapping implementing the current behaviour. I implemented a similar mechanism in sioyek: https://github.com/ahrm/sioyek/commit/b761840a95a8bc2f2e8095c8e8af743d38eabb7e
  • martynas_b
    Is there any other software doing this?
  • 2a18f1
    KOReader uses word boundaries. emacs pdf-tools allows changing the selection boundary (glyph/word/line, default word) using a variable pdf-view-selection-style. These are the two examples I'm aware of.
  • AbeJellinek
    EPUBs and snapshots use the browser's built-in text selection system. If you can find a way to get Firefox to use the selection behavior that you want, you should be able to apply the same customizations to Zotero and it would affect EPUBs and snapshots. If Firefox's selection behavior isn't customizable in the way that you want, though - and as far as I can tell, it unfortunately is not - there's nothing we can do re: EPUB/snapshot.
  • 2a18f1
    That's a good point; I'll take a look at it. In case this is not possible, would you accept a patch for the pdf viewer at least?
  • 2a18f1
    In recent versions of Firefox this stuff is implemented in `layout/generic/nsIFrame.cpp` in `nsIFrame::HandleMultiplePress` and `nsIFrame::MoveCaretToEventPoint`, which I assume are out of zotero's reach.
  • martynas_b
    It's true, we try to make all views (PDF, EPUB, snapshot) to be as consistent as possible. Also this feature isn't common or something that people would ask often.
  • 2a18f1
    Touch-based readers (besides KOReader e.g. Librera on Android -- I haven't tested any proprietary readers) often default to word-based selection. Considering that Zotero is also targeting those I'd argue that this feature will be relevant to Zotero. I can submit a PR once I've made the behaviour configurable; until then I'll be testing my patched version.
  • AbeJellinek
    When you say that Zotero is also targeting those, are you referring to Zotero for Android? If so, isn't word-based selection the default behavior on mobile in essentially all Android apps, Zotero included? You touch, hold, and move your finger to select whole words. Selecting individual characters requires releasing your touch, picking up one of the selection handles, and moving it.

    If you're talking about using desktop Zotero on a device with a touchscreen, I think text selection in the EPUB and snapshot readers should already behave the way you expect there.
  • 2a18f1
    Yes, I was mostly thinking about the Android app. Word-based selection works reasonably well under Android for html files, but not for PDF files: a long pressing a word creates a single-word selection, which can be changed on a character-level by adjusting the start and stop anchors.

    I've just tried the latest beta on a Surface Go (Arch Linux, KDE Wayland). With MOZ_ENABLE_WAYLAND=1 (or MOZ_USE_XINPUT2), highlights can be added using the touch screen after enabling the "highlight text" mode. Long touches do not work for this: they don't cause anything in the pdf viewer and open the menu that is usually activated on right clicks when interacting with the html viewer. The selection is character-based. The same applies to the HTML viewer. Without MOZ_ENABLE_WAYLAND or MOZ_USE_XINPUT2, selection works in a character-based fashion even without the "highlight text" mode, but scrolling breaks (as touch events are treated like mouse events).
  • 2a18f1
    Selecting text in firefox 122 using touch events does work, but not well: it's similar to the Android html file experience that I described above, just less smooth.

    Overall I'd say the best highlighting experience I'm aware of are all word-based, with character-based selection occasionally making sense when highlighting parts of words (e.g. typos) or with broken PDF files. I wouldn't want to force this experience on anybody though.
  • 2a18f1
    For epub/html I can implement a way to extend highlights to word boundaries. The distinction between single and double clicks would get lost in this case though. Would this be an acceptable solution to you? I wouldn't change the default behaviour of either reader.
Sign In or Register to comment.