How to make epub/mobi manga image occupy the entire screen?

[KaMyKaSii]

I'm not sure if this is just a question or a possible bug report. I did manga conversions for my Kindle Paperwhite 4 through Kindle Comic Converter with the option to resize the image but keeping the aspect ratio, so the expected result is no borders at the top and bottom of the screen. I did the same in both mobi and epub. In the standard Kindle reader, the mobi is shown as it should. In KOReader, both mobi and epub have borders making the image smaller. I've already tried messing with the KOReader settings like "View Mode" to "page" and enabling "Reclaim bar height from bottom margin" but no success. The only way I got the full screen images was with cbz files because there is the option "Fit: full". Any help is welcome. Thanks.

mobi with default kindle viewer:

mobi with koreader:

epub with koreader:

Proof by Calibre that the image height is the same as the KPW4 screen:

[NiLuJe]

You shouldn't really use MOBI in KOReader unless you like being miserable ;).

(The support is minimal to nonexistent, and absolutely unsupported).

[NiLuJe]

And you also probably shouldn't be using an ePub to handle primarily image content (e.g., manga/comics), as there's indeed some funny business involved around full-page images (can't recall the details, but, again, wrong format for that content type anyway).

TL;DR: Build a CBZ. That'll work flawlessly (and much, much faster).

[poire-z]

Forget MOBI, as we don't really support it.

About EPUBs, see that you really have no top and bottom margin via our bottom menu - and note that the minimal square in the progress buttons bar is not zero but 5px - so you need to use the 3 dots button on the right to set both top & bottom margins to 0.

If that's not enough, we'd need to see some sample HTML of a page including the image. Dependng on how your Comic Converter does it, some bottom margin might be per-specs, and may be you can tweak that with some Style Tweaks - but one needs to know what the HTML is like.

[KaMyKaSii]

And you also probably shouldn't be using an ePub to handle primarily image content (e.g., manga/comics), as there's indeed some funny business involved around full-page images (can't recall the details, but, again, wrong format for that content type anyway).

TL;DR: Build a CBZ. That'll work flawlessly (and much, much faster).

Okay, I'll give CBZ a chance. If you know of any tutorials to get the best results I would appreciate it.

Forget MOBI, as we don't really support it.

About EPUBs, see that you really have no top and bottom margin via our bottom menu - and note that the minimal square in the progress buttons bar is not zero but 5px - so you need to use the 3 dots button on the right to set both top & bottom margins to 0.

If that's not enough, we'd need to see some sample HTML of a page including the image. Dependng on how your Comic Converter does it, some bottom margin might be per-specs, and may be you can tweak that with some Style Tweaks - but one needs to know what the HTML is like.

You're right, when you set top and bottom margins to 00, the image takes up more of the screen, but there is still a space on the bottom margin. If I understand correctly, it's the 5px you mentioned, is it impossible to remove it at the moment?
I also noticed two other problems, for some reason KOReader adds a blank page between each epub page, which doesn't happen when viewing the same epub in Calibre. And KOReader also forces left-to-right reading in the file, even though the file was created with right-to-left reading, Calibre also works fine with this, using the left arrow to go to the next page. Should I create two other separate issues for this?

bottom empty space:

blank pages:

SM - 300ppi rename extension to epub.zip

[poire-z]

And KOReader also forces left-to-right reading in the file, even though the file was created with right-to-left reading, Calibre also works fine with this, using the left arrow to go to the next page.

We don't parse <spine page-progression-direction="rtl">. But a user can switch this with the top menu > Gear > Tap & gestures > Page turns > Invert page turn tap and swipes/buttons.

but there is still a space on the bottom margin. If I understand correctly, it's the 5px you mentioned, is it impossible to remove it at the moment?

(Sorry for the long write up, I was writting as I was investigating and testing and thought it would be quicker :) but you and other will see the process you might need to have when fighting publishers :)

No. What you take for the bottom margin is actually the part of a line of text below the baseline (in blue here):

There's some space below the baseline (to have room for the bottom of the p and g here), and inline images (images are inline by default), by default, sits on the baseline - so this is what you see.
There's no way to get rid of that bottom spacing (if we follow the specs for text layout) - except by making the image not inline.
So, with a style tweak containing img { display: block; }, you'll get its container to not contain any text, just blocks, and you won't get that bottom spacing.

Now, for the blank pages, each of your HTML contains crap after the image:

<body style="">
<div style="text-align:center;top:0.0%;">
<img width="870" height="1448" src="../Images/0002-kcc.jpg"/>
</div>
<!-- after here -->
<div id="PV">
<div id="PV-TL">
<a style="display:inline-block;width:100%;height:100%;" class="app-amzn-magnify" data-app-amzn-magnify='{"targetId":"PV-TL-P", "ordinal":2}'></a>
</div>
[...]
</div>
<div class="PV-P" id="PV-TL-P" style="">
<img style="position:absolute;left:0;top:0;" src="../Images/0002-kcc.jpg" width="1305" height="2172"/>
</div>
[...]

All these DIVs do not appear to be hidden by CSS, and they have some content - possibly empty text, but enough to generate some height which is what makes the following blank page.
Nope, even after removing them, we get the blank page...

So, it appears that even with the trick above, a standalone image makes its own baseline... (again, per-specs).
So, the trick that some publishers use (just remembered #8384 (comment)) is to make image "inline-block".
But it will still generate its own baseline.
So, let's make the line-height 0... and this works.
But there's still the crap mentionned above, that we should hide.

So, with this style tweak, you'll get what you want:

I'm not sure why Calibre displays that right, may be it has some tricks for this case.
But what KOReader does appears to be per the HTML & CSS specifications (EPUB and HTML being mostly aimed at text - that's why image-specific formats like CBZ are better for this kind of book).
I also think your Comic Converter may generate stuff enough for it to work with Kindle renderer - but it could have done better to get it to work correctly with a per-specs renderer (KOReader might not be fully per-specs, but it's close enough :)

So, if you continue using this Comic Converter to get that kind of book, you can make this book style tweak a user style tweak, so you can apply it quickly on future books.

[mergen3107]

Easiest way to convert manga to CBZ is to get manga if format of images from, for example, HakuNeko or websites, then covert using Kindle Comic Coverter. Take some time to learn settings, there are really useful ones. Such is the auto-rotate two-page splits to landscape.

Then, optionally apply dithering so that eink-rendered gradients are smoothly dithered without jagged layers. See my comments here: #2835

There is also on option in KOReader to apply right-to-left page turning depending (or many other settings) depending on the directory where the file is. I forgot the exact name and all, a little later I can show you specifically where it is (somewhere in the KOReader Wiki here, for sure).

Let me know if you need help, I pretty much madtered the hand-rolling skill of manga for einks :D

[NiLuJe]

I'd highly recommend hand-rolling your CBZs.

My own ePub -> CBZ workflow involves this shell script.

[KaMyKaSii]

@poire-z thanks for your research on this. It really seems too complicated to use book format for manga, I'll give cbz a chance.

@mergen3107 @NiLuJe I would like to ask you some questions. I intend to make my own cbz files but also distribute them for download to other devices, with screens with lower or higher resolutions than my KPW4. I would like to get the best visual quality on all of them. The obvious thing is to download the scam with the best quality, but in relation to the conversion of images, is it ok if I resize to a resolution greater than the screen of the devices that will use it, for example 1500x2000? Or maybe even higher resolution (eg for a future device proof cbz)? Will an image like this on, for example, a Kindle with a 600x800 screen have the same visual quality as an image with the same screen resolution or will it have any negative points? I would also like to know the difference between "-distort Resize" and just "-resize", I didn't find much information about this.

[Frenzie]

I'd go for 300 PPI or better (up to 450 or even 600), unless the source is lower of course. If we assume a screen size of 8", 1500 × 2000 is Just Right™. For higher, the best thing to do is simply to give it a go on your device and see whether it can deal with it. I wouldn't necessarily expect an old Kindle to have the memory to effortlessly deal with 3000 × 4000 for example. If you're automating the process, it might be worth considering offering a lower and higher quality version (e.g., at 200 and 400 or 300 and 600 DPI).

I'll point out that on Humble Bundle I like PDF comics sometimes, which come with a certain amount of vector elements so primarily the text is always the sharpest it can be. It's still nearly instantaneous to turn the pages but the file is a lot smaller. DjVu also has some tricks up its sleeves.

CBZ is fairly dumb but effective enough.

[NiLuJe]

The best result will require screen-specific CBZs (e.g., they need to target the exact screen size).

Whether you want to deal with downscaling at runtime is up to you, but I do NOT recommend it. Especially since we're adding a dithering pass in the processing, and scaling that will lead to terribad results (in general, and especially on eInk).

If you do intend to go this route, the least painful way might be to just use the CBZ made for your highest resolution device. Or pick an arbitrary "high" resolution (possibly one that matches the source?).

[Frenzie]

I think you're exaggerating a little (depending on the original resolution of course). ;-p

[NiLuJe]

Scaled dithering patterns are very very very bad ;).

[offset-torque]

@mergen3107

Let me know if you need help, I pretty much mastered the hand-rolling skill of manga for einks :D

Since you are knowledgeable and willing to help mergen3107, would you be interested in writing a section like "Preparing manga for KOReader" to be added to the user guide. I guess a sizeable proportion of our users are reading manga and this would be really helpful for many people with minimum effort. Instead of repeating the same things again and again, you can simply direct users to the guide if there is a question or discussion.

Of course others are welcome to contribute too. I think all these style-tweaks, tips for resolution, scaling, dithering etc. valuable knowledge should be preserved under an easily accessible place instead of being dispersed through issues like this. If I was a new KOReader user who reads manga, I would be very happy to find a section like this in the user guide.

[mergen3107]

@offset-torque
Great idea! I was thinking of making a good post on mobileread with this info, but your idea is even better. Let me work on this a little, no promises to finish this weekdays though, due to work =\

[KaMyKaSii]

Guys, after processing all images in imagemagick with dithering parameter, should I still enable Dithering option in KOReader or not?

[NiLuJe]

Guys, after processing all images in imagemagick with dithering parameter, should I still enable Dithering option in KOReader or not?

Obviously not ;).