End of chapter cut when there's a page break at the beginning

[agirtonea]

Describe the bug Zoomed in at 170%, when in paginated mode, the end of a chapter gets cut.

To Reproduce Steps to reproduce the behavior:

1. Open a book
2. Zoom in to 170%
3. Got to the last page of a chapter
4. Notice how the last 2-3 lines are missing. Turning the page goes onto a blank page and then the next chapter

Expected behavior You should be able to read all content when zoomed in. No lines should be missing.

Screenshots

Version:

• Foliate version: 3.0.1 and 3.0.0
• OS/Distribution and version: Fedora 39 and Flatpak on SteamOS 3.5.7
• Desktop environment: KDE
• Installation method: rpm and flatpak

Additional context The issue does not seem present in scrolled mode.

[johnfactotum]

Does this only happen with this particular book/chapter?

Does it happen with other zoom levels?

Is the end of the chapter a blank page even while it's showing the sliding animation? Or if you're using touchscreen or touchpad, does it show a blank page while sliding?

What happens if you start from the next chapter and turn back?

Does it happen in browser engines other than WebKitGTK? You can try it with the online reader: https://johnfactotum.github.io/foliate-js/reader.html

Since it shows a blank page rather than skipping to the next chapter, I feel that this could be a multicolumn bug rather than something that can be fixed in Foliate. But it's hard to say without reproducing this myself.

[Rektroth]

@johnfactotum I can't speak for OP, but I can give answers to these questions based on my own experience.

Does this only happen with this particular book/chapter?

I've only encountered it in a single book, but it happens with all chapters in that book.

(As OP stated, this is not an issue when "scrolled mode" is enabled.)

Does it happen with other zoom levels?

It occurs for me at all zoom levels, even the default 100%. Occurance is inconsistent, but can occur at all zoom levels.

Is the end of the chapter a blank page even while it's showing the sliding animation? Or if you're using touchscreen or touchpad, does it show a blank page while sliding?

It is a blank page even while displaying the sliding animation.

However, there is also some weird behavior with the sliding animation that I'll see if I can get some video of.

What happens if you start from the next chapter and turn back?

Still blank.

Does it happen in browser engines other than WebKitGTK?

The issue does not occur at all in your online reader.

Since it shows a blank page rather than skipping to the next chapter, I feel that this could be a multicolumn bug rather than something that can be fixed in Foliate. But it's hard to say without reproducing this myself.

Admittedly, this is really only an issue when the number of columns is set at 1. When the number of columns is set at 2 or higher, a blank page is inserted at the beginning of each chapter.

But, like OP, I prefer to read with a single column. And, as stated above, this is not a problem in your online renderer.

More recent testing confirms that issue can occur even with 2 columns.

If it would be helpful, I could email/Discord DM/etc a copy of the epub file this occurs with.

[agirtonea]

It does seem to happen primarily on one epub.

I haven't been able to reproduce it in the web browser because I see no way to change the zoom in-browser

Thank you @Rektroth for testing and confirming the issue.

[johnfactotum]

It's hard to see how this could happen. It's unlike anything I've seen. Usually what happens if the chapter is cut off is that it would skip straight to the next chapter. This is known to happen in Epub.js. But that's doesn't seem to be what's going on here.

One issue I've seen that is related to blank columns is that it will sometimes insert a blank column in the middle, which is almost certainly a WebKit bug. But again it's not what's happening here.

Still I'd say that this is probably not our bug. But one can investigate this further by using the Inspector (F12) to either inspect the blank page, or to click on the element that's being cut off and see how it's being rendered.

I see no way to change the zoom in-browser

You can zoom in in most browsers with Ctrl+= or Ctrl++ or from the hamburger menu (or the View menu if the browser has a menubar). If it is a WebKit bug it should be possible to reproduce it at least in Epiphany (GNOME Web). However it might be possible that the problem would only occur under a specific combination of window size and font settings, etc. that can't be reproduced exactly in Epiphany.

[Rektroth]

I'm a little confused what you mean when you say, "it's probably not our bug." The bug is occurring in your application. Even if the bug is originating in a dependency, I would think you'd still have an interest in trying to resolve this rather than hand wave it away like that. And, with all due respect, since you haven't even reproduced it yet, I think that conclusion is very premature.

I will now repeat my offer to send you any of the epub files this bug occurs with (which, btw, I downloaded and tested more files and now have a long list of examples).

As for using the inspector...

When on the page before the cutoff, the entire chapter, including the text that is supposed to be on the next page, is being rendered. But when I flip to the next page, I get a blank screen.

When on the blank page, the only thing being rendered is the next chapter - although it's offscreen, on the next page.

[johnfactotum]

I'm a little confused what you mean when you say, "it's probably not our bug."

It means that the issue might be caused by bugs or quirks in the browser's rendering of CSS multicolumn layout. For example, as mentioned above, I have occasionally seen an empty column being inserted in the middle of the page in the middle of a text node, which somewhat resembles, at least superficially, this issue. It happens rarely and inconsistently and I don't know why it happens, but it is most likely a browser bug because it goes against how text is supposed to flow in the multicolumn layout.

The bug is occurring in your application. Even if the bug is originating in a dependency, I would think you'd still have an interest in trying to resolve this rather than hand wave it away like that.

I did follow "probably not our bug" with how "one can investigate further." And even if it's indeed "not our bug", it just means that it's something that should be fixed upstream, it doesn't necessarily mean that it can't be worked around downstream. The code already contains many workarounds for upstream browser bugs. Actually, working with CSS multicolumn in general feels like working around one giant bug. The spec is lacking and the implementations are buggy. Still it's the best option one has for pagination unless one wants to roll one's own rendering engine. Anyway, my point is that it's not hand waving at all.

And, with all due respect, since you haven't even reproduced it yet, I think that conclusion is very premature.

It's not a conclusion at all. It's just a guess. Hence the "probably". The conclusion was more that "It's hard to see how this could happen" which indicated that I do not know why or how the issue is happening.

I downloaded and tested more files and now have a long list of examples

It would be best if you can reproduce it with a free book, or make a minimal test case, or use a tool to scramble the contents in the book (e.g. the ScrambleBook plugin for calibre).

When on the page before the cutoff, the entire chapter, including the text that is supposed to be on the next page, is being rendered. But when I flip to the next page, I get a blank screen.

But is the text that is supposed to be on the next page visible while the chapter is sliding out? You said, "It is a blank page even while displaying the sliding animation," which presumably means that the text is not visible while the chapter is sliding out.

When on the blank page, the only thing being rendered is the next chapter - although it's offscreen, on the next page.

This means that it's likely a foliate-js bug because, contrary to my previous comment, this shows that the previous chapter is cut off (similar to the sort of Epub.js bug that I mentioned).

Is the blank space inside or outside the iframe? If it's inside the iframe, then I'd say probably the book's content managed to insert some blank space at the start of the chapter (e.g. page breaks, empty elements, or paddings, margins, etc.) and this blank space is not accounted for when calculating the width of the chapter, which results in the end of the chapter being cut off.

[kzhe2059]

This occur ed to me but with high font size and not zooming in. The same book but mobi instead of epub worked, though.

[johnfactotum]

As speculated above, I can reproduce this when a chapter begins with a page/column break, which is used by some books to force the start of the chapter to be recto. (The "zoomed in" condition was probably a coincident where the chapter only ends on the verso side when zoomed in.)

The solution would be to account for the absolute position of the bounding client rect, which would also fix the underlying problem of #941.

A related but different problem is whether it should do anything special when there's only one column, in which case, rather than starting the chapter on the recto column, it would result in a blank page at the start. Possibly it can also use the position of the rect to detect and ameliorate this situation.