New renderer

[johnfactotum]

In the future, in the next major version, Foliate will stop using Epub.js and KindleUnpack, and use its own renderer, foliate-js, for opening books.

The renderer has a few advantages:

• Supports page slide animation and 1:1 swipe gestures (fixes smooth 1:1 horizontal scrolling gesture for touchpads #862 and [Feature Request] Page Flip Animation #188 (comment))
• It doesn't load the whole file into memory when opening (fixes Performance issues when opening large cbz files #813)
• It can get the correct sub-section TOC item without having to first load every single TOC items and convert them into CFIs (see Accelerate Preparing book first read #526 (comment)).
• Mobipocket and Kindle files don't have to be extraced on disk anymore
• Mobipocket files are now divided into sections at <mbp:pagebreak>s (fixes Why mobi format is slow? #764). NOTE: this will break existing annotations for this format. Existing highlights will stop being attached to the text.
• Reading progress can be shown instantly and there's no need to cache locations anymore
• When a page is not valid XHTML, it will fallback to HTML (fixes Render page as HTML if it's is not valid XHTML #699)
• Supports more than two columns (fixes More than two columns #257)
• Reflowing when resizing is faster and doesn't flash (fixes Double-flash when resizing windows #459). Also it will reliably stay at the same location, instead of having to manually correct the location like it currently does with Epub.js (see Resizing window resets current position #152).
• It has a collator-based searcher (fixes Ignore diacritics in searches #778)
• It parses the page when replacing resources (fixes Paths with extraneous dot segments are not replaced correctly #953)
• It supports obfuscated fonts (fixes Fonts are not deobfuscated #721)
• Improved fixed layout rendering (fixes Join spread #161 and Epub Right to left fixed layout navigation cannot turn to next page when in landscape mode #415)
• Current location has correct character-level offsets, instead of being based on space-separated words like Epub.js (which I think might be the cause of Foliate will jump to wrong location in Japanese books #502; at any rate the issue should be fixed)
• Doesn't skip pages for EPUBs from archive.org (fixes Page navigation skips random pages #929)
• Supports page-break-* properties (fixes page-break-after doesn't work #759)
• It has a workaround for Wrong size for CSS vw unit #223

This issue is an announcement, and also tracks all the issues that will be solved by the new renderer. It's also a call for testers. The demo viewer is very basic at the moment, but one can go to https://johnfactotum.github.io/foliate-js/reader.html and use drag and drop to open any file, to test if there are any rendering issues. There is also a branch that uses the new renderer as a Git submodule: https://github.com/johnfactotum/foliate/tree/gtk4

[elmagio]

I got curious and went and checked the foliate-js repo, and I couldn't help but notice the mention that it doesn't support continuous scrolling. Is that a current, pre-release limitation, or is that expected to be an immutable characteristic of it? Also, am I right in understanding that "standard" scrolling mode is still supported, and continuous (across chapters, ..) is what's affected?

I personally mainly use Foliate in continuous scrolling mode, though I could likely get used to regular scrolling mode if I had to.

Anyway I did throw a handful of EPUBs and MOBIs at the test reader, as well as a few CBZs, and it didn't seem to have issues with them.

[johnfactotum]

Is that a current, pre-release limitation, or is that expected to be an immutable characteristic of it?

It's still something that I'd like to add at some point. But I don't want it to be a blocker for the release. Though honestly, if it's possible to live without it (I believe Calibre doesn't support it, either, for example), I kind of want to just leave it out. Continuous scrolling adds a ton of complexity, and it seems impossible to eliminate unwanted flashing or shifting, especially on WebKit.

Also, am I right in understanding that "standard" scrolling mode is still supported, and continuous (across chapters, ..) is what's affected?

Yes, that's correct. It supports scrolled-doc, but not scrolled-continuous.

[elmagio]

Thanks for the answer ! For my use while lack of scrolled-doc would be a dealbreaker, scrolled-continuous by itself is a small tho welcome creature comfort. So if it's that big a headache, from my POV it's perhaps not worth it. But I'm just an user and can't presume of everyone else's needs and habits.

[johnfactotum]

It is now possible to switch to scrolled mode in the demo reader.

[brianclinkenbeard]

Excellent work! Epub.js's age and lack of maintenance have started to show; having a new renderer out there is going to be hugely beneficial.

[tomicakorac]

Steps to reproduce

1. Open any .epub file
2. Switch to Paginated view (Cog > Paginated)
3. Try to change pages by scrolling mouse wheel (any direction, forward or backward)

What should happen

• Pages should change (to higher number with forward mouse scroll, and to lower number with backward scroll)

What happens instead

• Nothing happens, the renderer does not detect the mouse scroll

Edit: The same issue exists for using keyboard arrows (left for back, right for forward), page up/down, home and end buttons.

[tomicakorac]

I'm not sure if it is the right time, or place to ask, but still: I'm noticing that the text shows in 1, 2, or 3 columns depending on the window width. Is it planned to offer users a setting for this? I would like to have the text shown in "pages" instead of columns, similar to how a printed book functions.

Edit: an edge-case, for very large screens (or very high viewport zoom-out) shows text in a large number of very long columns. I don't think if this is intended, or desired, but my initial gut-feeling (I know, completely subjective, but still) is that that's not how a book should behave. Maybe it's just a matter of getting used to it, but it's still worth considering any other possibilities.

[tomicakorac]

Is it planned to add any of the following:

• colour schemes? (Perhaps related to this, would you consider adjusting the colour scheme according to Ubuntu's light/dark theme setting?)
• Image opening on single/double click?
• Progress indicator (like the one currently existing along the bottom edge)?

[tomicakorac]

By the way, I must join the compliments, foliate-js looks like an amazing piece of work. Congratulations and thank you. I can't wait to test it in a desktop app and check whether it fixes the dreadful #879 😨

[johnfactotum]

Nothing happens, the renderer does not detect the mouse scroll

Yes, the demo viewer is highly incomplete. It doesn't handle any keyboard or mouse events yet.

I'm noticing that the text shows in 1, 2, or 3 columns depending on the window width. Is it planned to offer users a setting for this?

It currently supports only a max column width setting (I mean in the paginator's API, not in the demo viewer, which sets it at 720px), which also doubles as the max page width in scrolled mode.

It would probably make sense to add a "max number of columns" settings". To be really complete, I think a "min column width" setting is also needed, but perhaps it's not really that essential, and might be a bit confusing to use.

would you consider adjusting the colour scheme according to Ubuntu's light/dark theme setting

It already does that if your browser supports it.

Image opening on single/double click?

This will be in Foliate the GTK app, of course, but probably not needed in the browser, as you can just right click and copy/save/open in new tab, though I'm not sure how it would work in a progressive web app context (if that's ever something that's supported by the viewer).

Progress indicator (like the one currently existing along the bottom edge)?

Yes, there will be a slider. And as mentioned, it will be better because it will be available pretty much instantly, even for very large files. Whereas in Epub.js, it must process every single section before you can get a progress slider.

It might be somewhat less accurate, though, as it's based on byte size, not character count like Epub.js. Also sizes reported by the Zip file might not always be correct, so I guess a down side is that, for example, a malicious book could potentially trick you into reading it by pretending to have short chapters.

I can't wait to test it in a desktop app and check whether it fixes the dreadful #879 😨

I suspect it won't. Well, you can try opening the demo viewer in Epiphany or anything that uses WebKitGTK (generally, it's a good idea to test Epiphany if the problem is very likely that WebKitGTK is not working properly for some reason). If it works then it should work. But then that applies to the current version of Foliate as well. I guess sometimes it's only reproducible under very specific conditions (e.g. how the WebView widget is placed in GTK).

It does fix the problem that people fixed by deleting mime.cache, though (that's #878, by the way), because it loads from File objects (which is the reason why it doesn't have to read the whole book into memory), not by making HTTP requests to local files. Incidentally, doing this also fixes #544 and #391 (comment).

[elmagio]

It is now possible to switch to scrolled mode in the demo reader.

I hadn't realized this before trying it on the test reader, but it seems that scrolled-doc only allows scrolling through a single page for .cbz/.cbr files? As much as for book (EPUB, MOBI, ...) files being able to scroll through one chapter at a time is fine enough, this is an use case where scrolled-continuous offers a wholly different experience.

Tho I did now try both modes in the current Foliate release, and continuous scrolling mode does tend to chug quite heavily in the current renderer with large cbz/r files (I'd never actually noticed this because I typically just use Evince for comics), at least for me.

[tomicakorac]

I suspect it won't. Well, you can try opening the demo viewer in Epiphany or anything that uses WebKitGTK

Dang. Anyway, let's wait and see.

I don't think the issue described in #879 can be properly tested in the current foliate-js web renderer, because most problems are related to mouse and keyboard controls, and the bottom edge scroll bar, which are all missing from foliate-js for now. Those few that can be tested (e.g. loading a book, or moving through pages by very quickly clicking on the next/previous buttons) seem to be fixed. All issues from #879 still exist in the desktop app for me.

[johnfactotum]

@elmagio Yes, that's a fair point. The up side is that doing continuous scrolling for fixed-layout should be easier, and the result should be far less jankier, as you don't have to observe for changing page dimensions. The two renderers are totoally separate so one can try adding to the fixed-layout renderer first. And really, fixed-layout never really worked that well in Foliate (or Epub.js), anyway.