Furigana on page margins can create unscannable deadzones.

[4890A]

When reading an EPUB in vertical writing mode, the presence of furigana on the first line can 'push' the yomitan scanning region onto the previous page, making the entire paragraph unscannable. Words in this paragraph can still be selected normally with a click and drag, but not hover-scanned. This behavior can easily be reproduced by trying to scan the first lines of a furigana-heavy novel in the ttu ebook-reader. The displacement of the scanning region depends on various other alignment factors on the page; if the scanning region isn't pushed significantly far into the previous page, scanning will work as intended.

https://github.com/themoeway/yomitan/assets/16848266/593b880a-6418-4727-a816-a174f59afee4

Browser version 123.0.6312.123

Yomitan version 24.4.21.0

[4890A]

Just to clarify the issue, in <p> blocks such as these, any character that is not contained in a <rb> cannot be scanned unless a scan selection keyboard shortcut is used.

[jamesmaa]

Is this a ttsu reader issue or yomitan issue?

[4890A]

I don't think this can be fixed in yomitan without breaking something else. The getClientRects() for paragraphs like this are offscreen. Yomitan then decides to not display it at all since it thinks that the word it's scanning is offscreen. It's possible to ignore the isPointInRange check, but the pop-up ends up attaching to a random corner of the page.

Maybe it's possible to get a more granular rectangle when deciding where to place the pop-up, but I had trouble undertanding that portion of the DOMTextScanner.

[jamesmaa]

More context on discord https://discord.com/channels/617136488840429598/1231784381774041209

[Kuuuube]

A minimal reproducible example is going to be needed here.

[Renji-XD]

example.txt

For Chrome:

1. Rename file extension to html
2. Open html file
3. Open Device Toolbar
4. Select "Ipad Air" (820x1180px 75%)
5. Refresh Page

The first element on the right side has negative top values for client rect(s). All elements left from it will have proper top values of 0. When going to the previous site and hovering over the element you will see that the dimensions will report a width of 756px and a height of 2400px while the values under computed (+ js) show smaller values. Elements left from it have again the expected height of 1180px which matches the page height

Edit: the ruby text pushes the element out of the container area. Adding some padding like 10px on the side of the ruby parent seems to be ensure that the overall dimensions remaining in the box.. something we can try out on the reader. I don't think it is possible to target the last/first element on a column layout so i guess it would need to be accept that all elements are pushed a bit back

[Renji-XD]

for people who like to test if it fixes those cases on ttu without leading to other issues (if disabled) / completly disturbed ux. use an extension like stylus to add the content of the text file as custom css to reader.ttsu.app and reload the page

styles.txt