Looking up words with ruby is difficult on TTU reader

[RawToast]

Various minor issues with lookups can be solved by letting the user specify regex pattens. This is a useful feature in yomichan, which -- as an iOS user -- I'd love to have in 10Ten.

An example of such issues that can be resolved by the user can be seen here:

ttu-ttu/ebook-reader#28 (comment)

Furigana can often be hard to select. Often there's a specific place for compound words -- the second half of the first kanji. Anywhere else and the word will not be selected, when tapping this just quickly 'flashes' the selection colour.

This can occur for single, double, all the way to 4 kanji compound words. For these, I find the puck has to be used -- as selecting that space with my finger without using a massive font is hard, like the pencil does a better job but is still troublesome.

[birtles]

Thanks for filing this!

I'm sympathetic to wanting to be able to tweak settings to deal with specific sites without having to release a new version of the add-on but there's also a bit of a difference in target between 10ten and Yomichan.

10ten's focus is to be really simple, reliable, fast and to "just work". For example, we do a lot of work to tease out the text on sites like asahi.com and nikkei.com that's not possible with regular expressions. So, my initial preference would be find out what sites are not working with 10ten and address them specifically if we can.

Are there specific sites 10ten can do better at?

[RawToast]

Sure, furigana in epubs is the killer for me. Try ttu reader, 10ten works well for reading books now that ttu supports pagination. It’s very close to yomichan, except it struggles with furigana.

I hope this video demonstrates it well enough. Notice how it really struggles to select that full word, except for a specific spot, it’s worse when ‘tapping’ as you can even see something trying to handle the word… then give up. Sometimes I simple cannot select the word, other times I get lucky, So I have to either use the Apple Pencil or try the puck. By the way, I much prefer tapping to the puck 😊

This happens with single kanji words too.

No problems with this on the desktop, but I don’t use that as much. I believe this just requires the selection to ignore the furigana, which I know iOS and MacOS may erroneously select.

FullSizeRender.MOV

[birtles]

Thanks for that. That sounds like something we should debug.

I think most other reader apps just ignore furigana but 10ten tries to handle it which might be what's causing the problems on iOS. That's assuming it's actually marked up as ruby however, which not a lot of sites do.

Do you happen to have the data file available for reproducing this?

[RawToast]

I can reproduce it using the copy of 夢十夜 here: https://aohelp.club/search?word=夏目漱石

On the first page, the 判然 with ruby (はっきり) is a tricky one. AFAIK, ttu reader just uses the html from the pub. It might be different on iOS, but Safari on MacOS shows the following:

<ruby class="reveal-rt">判然<rt>はっきり</rt></ruby>

[birtles]

Ok, I think I made some progress on this. It looks like it's not strictly related to the furigana itself, it's just that when there is furigana there's a new element and a new text node.

On non-Gecko browsers which don't support caretPositionFromPoint we use caretRangeFromPoint. It seems like when using caretRangeFromPoint, if the cursor is less than ~70% of the way across the first character in a text span, it will return the previous text span.

You can see the exact cross over point in this screenshot where I added a red dot to the document at that point:

As a result, you need to actually tap in the last 30% or so of the character's width/height in order to target it.

In order to fix this, it seems like we need to add even more heuristics to the text look up. Perhaps something like:

• When using caretRangeFromPoint
  • If the offset equals the length of the startContainer's textContent, check if there is a text element under the passed-in point
  • If there is and it differs to startContainer use that and set the offset to 0