No margins on generated kepub

[occivink]

Picture of the original epub
Picture of the converted kepub

Note that the "margin" setting has no influence on the kepub one.

Both were sideloaded to my kobo aura one. I tried with different kepubify parameters but it made no difference.

The book in question is the french translation of War and peace from project Gutenberg.
Conversion log:

version: v2.3.1

output: .
output-abs: /mnt/data/media/books/Tolstoy, Leo
help: false
update: false
verbose: true
css:
hyphenate: false
nohyphenate: false
inlinestyles: false

fullscreenfixes: false

file: Guerre et Paix I.epub
  file-result: /mnt/data/media/books/Tolstoy, Leo/Guerre et Paix I.epub -> /mnt/data/media/books/Tolstoy, Leo/Guerre et Paix I.kepub.epub

Kepubify v2.3.1: Converting 1 books
Output folder: /mnt/data/media/books/Tolstoy, Leo
[1/1] Converting '/mnt/data/media/books/Tolstoy, Leo/Guerre et Paix I.epub'
  i: /mnt/data/media/books/Tolstoy, Leo/Guerre et Paix I.epub
  o: /mnt/data/media/books/Tolstoy, Leo/Guerre et Paix I.kepub.epub
  e: false
  de: true
  Unpacking ePub
  Processing 18 content files
  ..................
  Cleaning content.opf
  Cleaning epub files
  Packing ePub

n: 1
converted: 1
skipped: 0
errored: 0
errs: []

1 total, 1 converted, 0 skipped, 0 errored

Also another quick question: is fullscreenfixes still necessary now that removing header and footer has been officially exposed by recent firmwares?

[pgaskin]

That looks quite unusual. I'm going to look at the epub later this week and try and figure out why it does this in the kepub reader.

And no, --fullscreenfixes is not necessary anymore, as it seems to have been fixed. There's no harm leaving it on though.

[jasonperry]

I have the same issue, version 2.3.1 installed with brew on MacOS 10.14.3, Aura H2O v2, Software version 4.12.12111. Converted epub from (http://www.gutenberg.org/ebooks/31)

The left margin goes to the very edge, it overflows the right edge when justifying, and margin settings have no effect.

[pgaskin]

I had a look at some Gutenberg ebooks, and it seems their 0.5em margin on the body has a more specific CSS selector (body and a class) than the kepubify margin selector (just body).

Kepubs require a base margin of 0 for it to display properly, and I need to have a look at the margin overriding to see if I need to do more than make the kepubify selector more specific (html>body).

To fix this temporarily, you can remove the margin from the CSS in the epub.

[pgaskin]

Does adding the option --css "body {margin: 0 !important}" fix this issue?

[jasonperry]

I tried it for http://www.gutenberg.org/ebooks/863 and http://www.gutenberg.org/ebooks/31 and it did not work for either. I had previously tried deleting several margin settings manually inside the epub CSS, also with no luck, but I wasn't sure if I was hitting the right places.

[debiedowner]

It's not about CSS, the reason is explained here: https://www.mobileread.com/forums/showthread.php?t=276477

The KePub reader assumes that the first HTML file of the book is a cover page and automatically displays it in a special full-screen mode that is only suitable for images. If the publisher has included other material in the first HTML file after the cover, then that gets displayed full-screen too.

If you know how to do it then editing the book and splitting it into seperate files so that the first HTML file contains nothing but the cover image should fix the problem, or if the book doesn't have a proper cover page then using Calibre to add one is usually faily easy. Otherwise siideload the book as an ePub instead, as the ePub reader doesn't have this problem.

(Although if the publisher has combined the cover with other material into one file, then chances are they will have done the same thing in other parts of the book such as including multiple chapters in one file, and that can cause other problems with things like TOC and reading stats.)

I can confirm that the chapters included in the second html file and later were displayed fine in the kepubified ebook. I was able to get the initial chapters displayed correctly as well, by simply moving them to the second html file. There is probably a more elegant solution; I am not very familiar with the epub format yet. The cover still did not appear correctly, but then the original Gutenberg epubs did not display the correct cover on Kobo either.

I don't know if this fix would possible to do easily with kepubify (perhaps just adding a dummy html file at the start would work?), if not, kepubify will just have to have the disclaimer that it can only kepubify epubs that already obey the kepub constraints.

Or maybe, since Gutenberg epubs are popular and only they seem to have this issue, maybe kepubify or another tool can include a fix specifically for them, perhaps fixing the cover issue as well, if anybody is interested in implementing that.

[pgaskin]

Thanks for the info! I'd rather not add too many book specific workarounds to kepubify (and I'm trying to avoid adding ones to fix malformed epubs), but this seems to be one I could do.

I'll probably add an option to add a dummy cover page if the first page in the flow is more than a certain number of words or elements. Adding it will be simple enough, as all I'd need to do is add the doc to the manifest items and add the page to the beginning of the spine in the package document. In fact, I could probably do it using regexps if I needed to (kepubify tries to avoid touching the structure as much as possible), because I only need to insert an element directly after the start tag of each.

[pgaskin]

I've decided that a workaround for this is in-scope for kepubify, since it's a limitation imposed by the KEPUB format.

I will implement this for kepubify v4, which I'm planning to release sometime in the next week or two.

[pgaskin]

I've implemented this option in the pgaskin/rewrite-conversion-code branch. If you want to test this before I release v4, you can build kepubify from that branch.

[pgaskin]

I will be releasing this later this week.