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.

[tomicakorac]

Ok, this may or may not be related to #879. When I open a new tab in Epiphany, paste the url https://johnfactotum.github.io/foliate-js/reader.html and hit enter, the page seems to load but does not display (I only see white viewport). Only after I reload the same tab, the content displays. If I open a new tab and try the same, I get the same white page the first time, and content loads only after reloading.

In other brosers this issue does not occur (tested in Vivaldi, Chromium, Firefox).

I wonder if anyone else experiences the same?

[johnfactotum]

Are you using dark mode? I believe it's a bug in Epiphany when opening a page with color-scheme set to light dark, dark light, or just dark. I don't know if it's an WebKitGTK or an Epiphany bug. It doesn't happen on a plain GTK 4 WebView, at least. Probably not directly related to the issue,

[tomicakorac]

Yes, I am indeed using dark mode, good catch. After switching to light mode, the above issue is gone, thanks a lot. I'm relieved now :)

[smith558]

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?

For me [personally] the continuous scrolling is a must, especially when reading technical books and similar.

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.

Just adding some more user feedback. For me definitely as well, continuous scrolling is a must. Across-chapters scrolling is nice to have, but not a deal-breaker.

[johnfactotum]

Just adding some more user feedback. For me definitely as well, continuous scrolling is a must. Across-chapters scrolling is nice to have, but not a deal-breaker.

Continuous scrolling == Across-chapters scrolling

[rwperrott]

For v2.6.4 and a prior version.
It looks like the renderer (this one, I assume) is still broken for some sigil validated epub files (render "spinner" forever on open), and I can't see how to get (enabled) developer mode to show in this state, to at least get some hint of what's causing this, so that I can log it.

[johnfactotum]

2.6.4 and prior versions use Epub.js, not the new renderer. The gtk4 branch uses the new renderer.

[BabaJi-0]

I tried to use gtk4 branch on Fedora 37. All dependencies are pre-installed I guess. I am facing same "forever loading" issue on every epub I tried. No error show up. Only something like this when I click navigation keys.

(com.github.johnfactotum.Foliate:7466): com.github.johnfactotum.Foliate-CRITICAL **: 00:33:06.388: Can't find variable: reader
@foliate:///reader/reader.html:1:26
@foliate:///reader/reader.html:1:41
global code@foliate:///reader/reader.html:1:42
reader.view.goRight

edit: My bad, foliate-js wasn't cloned. Added --recurse-submodules and it worked. Sorry for taking your time.

[rkjnsn]

Should issues discovered be posted here or as new bugs on the foliate-js repo?

[johnfactotum]

Well, I guess logically, if it's a general issue concerning the idea of using the new renderer, it would be appropriate to leave a comment here. If it's clearly a bug in foliate-js itself, then file it against its repo. Otherwise it would make sense to create a new issue against this repo.

[Donatzsky]

Just tried, in Firefox, with the v2.2 test epub from here: https://www.mobileread.com/forums/showthread.php?t=148097

The only (potential) issues I noticed were:

Pagebreak Test
No page break after the first paragraph.

Scale Tests
full height is always 'collapsed', never full height.

white-space: nowrap
The very long line with white-space: nowrap is truncated. Most other readers I have tried allocate more pages as needed.

[johnfactotum]

No page break after the first paragraph.

This is a limitation of using CSS columns and it's also a problem in Epub.js and other column-based renderers, as page-break-before: always does not work in CSS multi-column layout.

There's -webkit-column-break-before: always and break-before: column, which I believe are the only ways to force breaks within multi-column layout. Note that neither are supported by Firefox.

So I guess the solution is that Foliate should replace page-break-* with -webkit-column-break-*. There is a PR for Readium SDK that solves the same problem with this approach: readium/readium-sdk#229

full height is always 'collapsed', never full height.

For height: 100% to work, all parent elements must not have auto height, I believe. In WebKitGTK and Chromium, if you add height: 100% on the body, the div behave as expected (although break-inside seems to be ignored by WebKit). This still doesn't work in Firefox, though, which is probably a Firefox bug.

This issue doesn't happen in Epub.js, but it's actually just a side effect of foliate-js setting the column layout on the root element, whereas Epub.js does it on the body. I believe the former is more desirable as it allows the book to "own" the body element more (to e.g. add padding or border to the body element, which isn't really possible with Epub.js).

The very long line with white-space: nowrap is truncated. Most other readers I have tried allocate more pages as needed.

This appears to be specific to Firefox. On WebKit and Chromium, it does allocate more pages.

I'm not sure which is more correct, spec-wise speaking, in terms of whether getBoundingClientRect() should include the overflow. I think Firefox might be doing the correct thing here.

[chromer030]

Hey, Is it possible to make Foliate compatible with qt-webengine ? (i mean possibility to use qt-webengine as backend instead of webkit2gtk)

This is useful on KDE Environment, as the qt-webengine is a default dependency.

[johnfactotum]

Foliate uses GTK, not Qt, so it can't use qt-webengine.