The attached image demonstrates a recent regression in the double-page reader that started sometime in the last few versions. That is, page grouping is correct until the reader encounters a double page. After that, a single page will display and following that the pages will be grouped with the gutter on the outside rather than the middle, and I have to reset it by long-tapping the single image and saying “group from this page on.”
Maybe I’m missing something, but I wouldn’t consider this a regression or even a bug. 
The reader assumes that a landscape page corresponds to a double page. Hence, the previous two vertical pages before must be single pages and must be paired.
The first page is the cover, and the reader never pairs it with the next one. From then on, they are assumed to be single pages and paired in order.
Some files add additional covers or art pages, which shifts the order. That is perfectly fine when the shift is even. Otherwise, the grouping might result incorrect.
The “group from this page on” action exists to work around this problem manually.
By looking at the screenshot you attached… I don’t understand how that file is intended to be grouped. It looks like the original manga in its physical edition didn’t have those two pages side by side. But the person who edited that cbz/cbr decided to combine them in a single image to make the art on the top appear as a single panel. I think the right half of page 101 was originally on the left page of the manga, paired with 100 on the right. And the second half of 101 should be on the right, paired with 102.
As I said, let me know if I’m missing something and I’m not getting the point.
I’ve never noticed the behaviour since the “group from this page on” feature was introduced, until just recently, but I was thinking about it on the way to work and realized that it may have been “accidentally working”, so.
No, those two pages are physically beside each other. Since the preview displays “Image Numbers” and not “Page Numbers”, here is what the pages in the preview correspond to in the physical book:
image 97 = page 96
image 98 = page 97
image 99 = page 98
image 100 = page 99
image 101 = a single image containing page 100 and page 101
image 102 = page 102
image 103 = page 103
image 104 = page 104
Manga is printed with Page 1 starting on the left, and then each subsequent group of pages starting with an even number on the right and the following (odd) number on the left.
Electronic releases are always released in single page images, but when packaging CBZ file, people often stitch together double pages into a single double-width landscape image.
In the preview, the pages 96-99 (images 97-100) are grouped together correctly, as can be seen by the gutters in the centre being blank (and bleed areas fully used on the outsides). Then pages 100-101 (image 101) are also correctly displayed as their own “group” because it’s a landscape image containing two pages. But it goes wrong when Page 102 (Image 102) is somehow assumed to be on its own. In the next group, because the odd page is on the left and even is on the right, you can see that the blank gutters have migrated to the outside of the pages, and the bleed area moved to the centre.
Correct. But mustn’t the next two vertical pages also be single pages and therefore must be paired?
It kind of feels to me like there is some sort of logic that’s attempting to make the book not only start, but also finish on a single page.
Hello @awh
We’ve double-checked the code and it seems like there might be some edge case for right-to-left reading. We will take a look and try to fix it for the next version.
As a workaround in the meantime, you can long press the page that’s incorrectly grouped and tap “group from this page on”
Would you mind sharing that comic file with us?
Sent a link to the file via PM. Thanks!
Hey, @awh thanks for the file!
We found out what was going on. The grouping is working correctly, though the “Group from this page on” feature is not. Instead of using the correct page, it uses the position (index) in the list, which is inverted when reading RTL. Meaning that when you group from page 2, it’s grouping from 196. We will fix this shortly.
Nonetheless, there is a problem with the file. In the video attached, let’s use the two black pages (92-93) as a reference. Those two are meant to be paired. 101 has a landscape aspect ratio, making it a double page. If you count the pages between 93 and 101, they are odd. Which makes them impossible to pair correctly. Also, if you look a few pages ahead, and count the pages between 101 and 117 (the next black page which should appear on the right, paired with 118), they are odds again.
101 is incorrectly merged. It should be two different pages, and they would pair perfectly with the ones left unpaired on both sides.
Here’s the same thing, both on LTR and RTL.
LTR
RTL
Bottom line: We have to fix the “Group from this page on” feature on RTL, which is clearly broken. But that won’t solve the issue with this particular comic/manga.
Let me know your thoughts.
They aren’t meant to be paired. In this book, the two black pages run between chapters. Each chapter ends on the right, then there’s a black page on the left that says “Hi Score Girl”. In the next group, there is a black page on the right (a video game controller I guess) and the beginning of the chapter on the left. You can tell they’re paired correctly when the majority of the groups have a white space in the centre (where the crease in the book would go).
If you want I can send you a different file that exhibits the same behaviour. It has page numbers printed on the book itself, so it’s easier to see when the odd page numbers switch from being on the left to on the right. Also, I made the file myself so I know 100% that the joined pages are supposed to be joined.
I just sent you another file; the behaviour is a bit easier to see in this one.
Like every Japanese release I’ve ever seen, it starts with the cover, and then a blank page immediately so that the first group is the two images after the cover. I can’t remember if I had to use “group from this page on” or not, but you know the grouping is correct if a) the page numbers are on the “outsides” of the groups, and b) the odd page number is on the left.
There’s only one joined image in the file, Page 158-159. Before that, 156-157 are grouped correctly. Then the single image containing 158-159 is correctly displayed alone. After that, 160 is displayed alone. Then 161-162 incorrectly display as a group (it’s hard to see because no page numbers are written on those), and when you get to the next group, its quite easy to see that the grouping was changed because 164 is on the left, and the page number is in the centre of the group. From then on, all groups remain incorrect until the end of the book.
Thanks for clarifying 
Nonetheless, it’s the same idea. The initial block of pages is not even because they are missing that blank page you mentioned. Page 2 shouldn’t be the second in real life. It should appear on the left side of the manga, so it would be page 3 (or page 2 if you don’t count the cover as page 1). That page shouldn’t be paired because in real life it’s paired with that missing blank page.
The bug with the “Group from this page on” makes everything more confusing, but the grouping logic is correct.
Check this video:
The current bug is that “Group from this page on” incorrectly uses the index of the list, not the page number. As a workaround to group pages from page 3, we can use page 195 (3rd to last). Doing so, groups the comic from the 3rd page on. Doing that, the grouping is perfect and matches what you described.
The combination of an uneven number of pages + the wrong “group from this page on”, creates the problem.
Landscape pages are “anchor pages” and the rest are grouped based on those. “Group from this page on” creates another anchor page so that one is the first of a group.
Another thing to point out is that whenever you rotate your device from vertical to landscape, you are implicitly “Grouping from the current page on”. Given that feature is clearly broken in the current version, pages appear different from what you’d expect.
We will fix this in the next few days. I’ll post a Testflight with that fix so you can try it and let us know if it solves the issue.
Let me know if all makes sense.
My point is that this manga can’t be grouped correctly automatically because the pages are not even. It needs the help of the user by using “Group from this page on”. Given that the feature is broken on RTL, the bug appears because it creates an incorrect anchor page.
If the file had even pages, the grouping wouldn’t look wrong because the landscape page creates an anchor point, and the “group from this page on” anchor, even being in the wrong place, pages would group correctly. After all, they are even numbers.
The bug is not in the grouping logic but in the index of the anchor page.
You’re right, I think the wrong “group from this page” is clouding the situation, so let’s at least wait until that’s fixed. At least the second one I sent should have been correct regardless, and I’m not sure quite how it ended up wrong on one side or the other
I actually think that any (properly formed) manga can be grouped correctly, even if there is an odd number of pages, if there is at least one landscape image. Here are the possible cases:
-
No landscape image in the file: Complete guess. Never pair the front cover with anything, and after that pick another grouping and let the user manually group if it’s wrong.
-
Exactly one landscape image in the file (like the second file I sent): That’s the anchor image. Groups should be in twos for each image after and before that image, spreading outwards towards the beginning and ending of the book. Never pair the front cover with anything; but pair the back cover if that’s the way it ended up.
-
Two or more landscape images in the file, as long as there is an even number of portrait images between each one: Same as above
-
Two or more landscape images in the file, but there is an odd number of portrait images between any of them: This is a malformed file so just pick a random grouping, and let the user fix it manually as punishment for downloading a malformed file.
Anyway, I’ll wait until the “group from this page on” is corrected and see if that fixes the issue.
OK, and separately I finally got it through my thick skull why the incorrect “group from this page” is screwing it up – because it creates an artificial (and incorrect) constraint on the wrong side of the double image. So you’re right in that it will almost certainly solve the problem.
Exactly!
We have 2 constraints: the landscape page and the one created by the “group from this page”. Those two + uneven number of pages make everything fall apart.
I’m pretty sure when I fix the “group from this page” feature, everything will make sense.
I’ll try to submit the Testflight today. It should be an easy fix. Will add a bunch of additional tests to avoid regressions.
@awh We finally got the testflight approved by Apple. 2.14.2 should be available now and it includes the fix for the “group from this page on”.
Let us know your thoughs
I’ve read 4 books and no complaints so far! Thanks for the quick fix.
Eventually it would be nice to infer the correct grouping for pages before the first landscape image, but that’s pretty far down on the importance list.
Excellent! thanks for confirming
Eventually it would be nice to infer the correct grouping for pages before the first landscape image, but that’s pretty far down on the importance list.
Yeah, I would love this too but we need to find a good approach for this.
The main problem is that, to do that, we need to extract all the pages in advance, meaning that you would have to wait until we analyze the whole file to know the geometry of the page.
We did this in a few versions, and the experience was quite bad in our opinion.
Large files are particularly common in Manga, and enabling the double page reader on RTL mode would block the reader for a few seconds, sometimes minutes, until the file was completely analyzed.
We decided to change the approach and now the geometry is calculated on the fly while you read. The readers pre-load the 2 adjacent pages, so when you are reading page 5, it already knows the geometry of 3,4,5,6,7.
The problem gets even more complicated if you consider synchronized reading sessions.
The geometry is calculated and cached locally. But if you open a file that you have never opened on that device, but you already have a reading session that is at 50% progress, for instance… The reader will load the page, let’s say, 50, and calculate the geometry of 48,49,50,51,52. But won’t know the geometry of 1…47. It will have to assume they are all unique vertical pages.
We thought about pre-calculating the geometries in the background after you import the files. But you could import hundreds of them, and there’s no way of knowing which one of them you will open first to optimize the order of analysis.
We ended up taking the “calculate on the fly” approach, which has some limitations, like the one you mentioned. It can only calculate so many pages’ geometry to know how to group them.
Hopefully, in the future we design a better approach.