Koreader does not handle djvu files with varying page size correctly

[tigran123]

Although I have tested this with DjVu files, namely this one:

http://www.bibles.org.uk/Long-Heads-and-Round-Heads-1918.djvu

the problem probably manifests with PDF files as well. Namely, do this:

1. Select the Crop function from the bottom menu and then select "manual" mode.
2. Don't change the box borders (the file is already perfectly trimmed --- I have cleaned and processed every page by hand).
3. Now start reading from the beginning and reach physical page 30 (logical page 20).
4. Notice how it is displayed incorrectly, i.e. NOT in page width manner. Rather, it occupies the proportionate (relative to the previous/normal page size) area on the screen and surrounded by the junk which comes from File Manager (i.e. "10 items" on the right etc etc).
5. Even selecting Crop box and "manual" again does not remedy the situation.
6. After you reach page 32 (logical 22) everything is back to normal again, as the page size is again the larger one.

[chrox]

This bug is confirmed. But it raises a question on how we interpret the manual cropping box. If the pages have different physical sizes, current manual cropping should make no sense. Because the odd/even crop box for other pages (absolute pixel values) may not suitable for current page because they have different physical page sizes.

One way to solve this is storing cropping box as proportional values, i.e. left 5.3%, right 6.8%, top 2%, bottom 2% and applying these values to new pages.

[tigran123]

Storing bbox dimensions as proportional values sounds like a good idea, but we need to think carefully whether there are cases where this is inappropriate.

[tigran123]

I can't think of any situation where @chrox 's idea wouldn't work.

[chrox]

I have changed my mind. The proportional values for cropping box is meaningless and not a good idea. The reason is that even/odd bbox has an assumption that page numbers have the of the same parity have the same page layout and size so that manual crop box of one page can be reused for other pages of the same parity. It's a little crazy to assume layouts of two different sized pages are same. We even cannot assume the layouts are similar with a proportional factor.

The solution I can think up is that:
when a page has a smaller page dimension than a bbox, the page should be zoomed to fill the bbox without cropping so that the visual defect you described above won't occur.

[thotypous]

The though question here is that different documents have varying page sizes for different reasons.

If you scan a document using fixed scanner dpi resolution and run some automated cropping, you may end up with different page sizes because of the non-normalized cropping, and in this situation resizing the pages to the bbox would end up making font sizes uneven from page to page. In this case, a better solution would be to draw a gray background and center the page on it, rendering it with its original size.

However this solution would not work on documents like tigran's one, where the chrox's solution of zooming to fill the bbox is the best one.

I think that chrox's solution is the best one overall and the uneven font sizes I mentioned in the first situation would not be such a big issue for reading the document.

[tigran123]

If I understood correctly, then with this solution those two pages in my sample document would now be rendered in "fit page height" zoom mode even though the reader selected "fit to content width" zoom mode via "manual" crop option in the menu. This is, at the very least, inconsistent and unexpected to the user.

With the bbox values defined as proportions those two pages would have been rendered in the same "fit to content width" zoom mode, just like the rest of the document and if their margins occupied the same proportion of pixels then everything would be fine. Now, if the margins on those peculiar pages are significantly different (i.e. occupy larger proportion in terms of number of pixels) from the margins on the other pages, then there is nothing the software could possibly do (short of heuristic guessing of whitespace threshold) and the bad rendering could still be fixed manually by selecting crop icon from the menu and then "manual".

Am I right in assuming that with the present @chrox 's solution one would be unable to read those two pages at all? I.e. they would be so small as to be unreadable and it would be impossible to switch to "zoom to content width mode"? If this is the case, then the bug is still there and the incident should be re-opened.

[chrox]

Nope, you can always override inherited bbox from parity match by cropping that page manually. So if those two pages has a lower zoom level (actually they are zoomed to fit page if crop box is larger than native page size) you can simply recrop that page manually, it will be zoomed to fit content width as long as the crop box is smaller than the native page size.

In general, manual cropping needs more ad-hoc adjustments which is more suitable in documents that have variant page layouts for different pages.

[tigran123]

Ok, then everything is fine. Thank you very much, @chrox both for fixing the problem and for taking the time to explain the solution. I look forward to testing the next nightly build.

[chrox]

By the way, there is an Over-The-Air update function for Kindle and Kobo devices with which you can keep your Koreader devices updated more regularly. OTA builds will be synchronized automatically to the koreader master branch every 12 hours. You can find it at "Info"(the fourth icon in the upper menu) - "OTA update" - "Check update".

[tigran123]

Unfortunately, the OTA function does not work. After touching OK on the "Do you want to turn on WiFi?" it hangs for a couple of minutes and then returns back to the FileManager.

Note that my WiFi works fine in nickel. Presumably, for OTA to work one has to leave WiFi Enabled in Nickel. But I always set it to Disabled because otherwise if I accidentally boot into Nickel it may download and upgrade the firmware which may break my entire startmenu+koreader+vlasovsoft infrastructure.

[tigran123]

Btw, I have just tested on the emulator and you (@chrox ) are absolutely right --- the behaviour is exactly how I wanted it to be. Thank you very much. Looking forward to the latest nightly build (hint, hint :)