[davidfor]

Originally Posted by Rev. Bob

The problem is not margins, but proportions. The Kobo dimensions are 3:4, which normally plays out as using a 600x800 cover image. However, many ebooks out there use a 600x900 image instead.

There are three ways to handle that: stretch, zoom/crop, or box. Nobody zooms/crops that I've found; I mention it only for completeness. Best I can tell, Kepubs stretch; the 600x900 becomes about 675x900 and fits the box, but there's some "short and fat" distortion. Standard epubs box instead, and since the default background color is white, you get white stripes down both sides.

For sideloaded epubs, the size of the actual cover image inside the files is unimportant. The device renders what it thinks is the cover page and creates an image from that. In doing that, it is using CSS for that page from the epub, and the current reading settings from the device.

One trick that worked before 2.4.0 was to tweak the OPF and make the cover image the first element in the <spine> element, but set to non-linear so it wouldn't come up as the first visible element.

That is interesting. I usually say that the first page of the book is used as the cover. Most of my epubs do have the first page as the cover, and when I edit epubs that don't, I "fix" that. But, thinking about it, I have seen this behaviour for a couple of epubs before I started changing them.

Unfortunately, 2.4.0 has changed rendering behavior so that the device uses the first item in the spine to set the book's rendering area - meaning that if you have a small cover image there, you get huge margins to the right (and possibly bottom) of your book, and there's no way to "zoom in" and fix it.

Are you saying that whatever is used on the first page then affects all the rest of the pages when reading? Or is it just affecting the generated cover? I haven't seen the former, and the latter sounds like what I would expect to happen. Have I misunderstood this? In any case, I'll have to do some experiments to see what is happening here.

I've taken to writing my own cover-page code, where I can control the colors and lock in some other formatting. The files are small, and the structure is pretty simple overall, but it's not just a drop-in replacement. After all, you do have to put the right image locations in, and sometimes you want to preserve some IDs from the original page. However, it's a lot better than before; a black background isn't perfect, but I like that better than white bars most of the time.

I can understand that. I see a few books where the CSS for the cover page is quite different to the rest of the book. It can get around some of these problems.

There is a change in 2.3.1 and later that hasn't been mentioned in this discussion. For the home page and lists, the aspect ratio of the cover images, are respected. This means that a cover image is put onto the device for a book, it will be resized to fit the different places, but the aspect ratio of the image will be kept. Pre 2.3.1, the images were always force to be 3:4 ratio. Now they are not. If the cover image is generated by the device, is it still generated as a 3:4 ratio from a rendered page in the book.

I have made some changes for the calibre driver to handle the aspect ratio when sending a book. I have the changes with some testers and hope to have it in this weeks calibre, but it might be next week.