If the viewer is running in an RTL context (this is not the same as the
reading direction of the Book itself), and a fixed-layout rendered view
is scaled (which is often the case), anchoring the transform to the
left breaks page positioning.
In Safari, clicking on links triggers `selectionchange`. Since we do not
move the caret when flipping through pages, when you have flipped to the
next or previous pages and click on any link, it would take you back to
the caret instead of activating the link.
Note that the bug occurs in Safari 17 but not in WebKitGTK 2.46.
Not sure if there's a way to fix this and still retain the "set anchor
to caret on click" behavior. But I guess this behavior isn't really that
essential, anyway. So removing it for now.
Fixes#44
Previously, zip.js and fflate were built from the main Foliate repo.
And PDF.js files were copied manually. Now they all build here.
Unfortunately, two CSS files still need to be copied manually.
The book object is not created by the view class so it has no business
destroying it.
Fix bug caused by 1e952102bd where closing
the footnote view destroys the book, when it should not be destroyed,
being still displayed by another view
The fixed-layout renderer now accepts an object for the return value of
`load()` (on the `book.sections` items). If it's an object, the `src`
is the URL of the section, and `onZoom`, if present, will be called
when the viewport is zoomed. With this you can scale the page yourself
rather than relying on the renderer's own scaling with CSS transform.
Also upgraded to PDF.js 4.6.82. And now internal links are broken...
Don't know how to fix that yet.
The view follows caret when using caret browsing (F7). Also allows
selecting across pages. And if you click on or select some text and
resize the window, the caret/selection always stays visible.
Some quirks regarding caret browsing:
- In Chromium, in paginated mode, it scrolls when changing selection
(https://issues.chromium.org/issues/40889650)
- In WebKitGTK, in scrolled mode, the view doesn't follow the caret
(which would be a WebKit bug)
What's `margin` doing here?! It's like this since the first commit, but
it makes no sense... I think I added it incorrectly, being misled by
the getBoundingClientRect bug in Firefox...
Huang Xin
John Factotum
Protected
Ray-D-Song