kepubify - A standalone tool to convert ePubs into Kobo ePubs

[geek1011]

Originally Posted by trekk

I got a "no permission" message in my terminal, so I had to chmod kepubify on my mac. Conversion is very fast, but without the possibility of a batch conversion, Calibre is faster when converting multiple files. Nice tool though!

Edit: I also realized that the new .kepubs don't show a thumbnail of the cover on my KA1.

Covers should be fixed now.

[DNSB]

Originally Posted by davidfor

From the very few rules we have for kepubs, every file is supposed to have a ToC entry. In some purchased books, I've seen things like "unnamed chapter" or the first line of text as the title. I think Kobo's publishing routines are adding these as needed. If there are missing entries, you can get some strange things happening with the chapters and page counts. (I might have to check that as it has been a while).

You could apply hidden to those added epub3 nav.xhtml ToC entries though as far as I can tell from reading the epub3 spec, there is no requirement for every file to have a ToC entry though a spine entry is required.

Looking at the kobolabs epub information kobolabs/epub-spec , Kobo's CMS will add files listed in the spine to the ToC for epub2 files if there is no existing toc.ncx file. For epub3, an existing nav.html (should be nav.xhtml) will be used followed followed by toc.ncx and finally, if toc.ncx does not exist, the ToC will be generated from the spine listing.

Given that the epub2 spec requires a toc.ncx and the epub3 spec requires the navigation document, adding spine files to the ToC should never occur for a standards compliant epub.

[geek1011]

I will be away for about 8 days starting tomorrow.

[davidfor]

Originally Posted by DNSB

You could apply hidden to those added epub3 nav.xhtml ToC entries though as far as I can tell from reading the epub3 spec, there is no requirement for every file to have a ToC entry though a spine entry is required.

Looking at the kobolabs epub information kobolabs/epub-spec , Kobo's CMS will add files listed in the spine to the ToC for epub2 files if there is no existing toc.ncx file. For epub3, an existing nav.html (should be nav.xhtml) will be used followed followed by toc.ncx and finally, if toc.ncx does not exist, the ToC will be generated from the spine listing.

Given that the epub2 spec requires a toc.ncx and the epub3 spec requires the navigation document, adding spine files to the ToC should never occur for a standards compliant epub.

The kobolabs document is the point. It is the only thing that comes close to giving specs for kepubs. It states there must be a ToC entry for each file. It doesn't really matter what other specs say, it is how Kobo have interpreted them and implemented their readers. And that's a lot of the point as well. A kepub is not actually either an epub 2 or a kepub 3. It is Kobo's interpretation of those two spec plus things that they added. Such as ignoring the widows and orphans in the CSS, and the spans wrapping sentences. And requiring that all files in the book are in the ToC.

The Kobo publishing routine make sure this that the generated kepubs match their standards. But, none of the ways of generating kepubs for sideloading make sure of this. I think they are close, but none make sure the ToC is complete.

[DNSB]

Originally Posted by davidfor

The kobolabs document is the point. It is the only thing that comes close to giving specs for kepubs. It states there must be a ToC entry for each file. It doesn't really matter what other specs say, it is how Kobo have interpreted them and implemented their readers. And that's a lot of the point as well. A kepub is not actually either an epub 2 or a kepub 3. It is Kobo's interpretation of those two spec plus things that they added. Such as ignoring the widows and orphans in the CSS, and the spans wrapping sentences. And requiring that all files in the book are in the ToC.

The Kobo publishing routine make sure this that the generated kepubs match their standards. But, none of the ways of generating kepubs for sideloading make sure of this. I think they are close, but none make sure the ToC is complete.

That's not the way I read it. It mentions all files in the spine that are not in the toc.ncx being added to the ToC for files that do not possess an epub3 navigation document and also states that this process may be removed in a future release. Since a standards compliant epub3 requires that navigation document, there should be no modifications done a standards compliant epub3 navigation document which suggests that there is no need for all spine items to be in a navigation document.

[rashkae]

Regardless how how you read it, if this is not done, the books glitch in Kobo.. (For that matter, as of the latest batch of releases, books without a complete ToC also glitch in the Epub reader, but that's a different issue. I can safely call that one a bug.. But Kepub needing a ToC entry for every file has been 'as designed' since forever.)

[DNSB]

Originally Posted by rashkae

Regardless how how you read it, if this is not done, the books glitch in Kobo.. (For that matter, as of the latest batch of releases, books without a complete ToC also glitch in the Epub reader, but that's a different issue. I can safely call that one a bug.. But Kepub needing a ToC entry for every file has been 'as designed' since forever.)

Interesting. I read mostly epub2 books and I haven't seen a glitch due to an incomplete ToC -- my practice when editing an epub2 is to modify the ToC so the first page of the book contents (i.e., prologue, chapter 1, etc.) is the first entry in the toc.ncx. As for kepub needing a ToC entry for every spine listed file, it is pretty clear that a epub3 with a navigation document will not have all the spine files added into the navigation document. I've quoted the relevant portion of the Kobo documentation below:

**For ePub 2.0.1**, Kobo reading platforms populate the ToC menu in the book with the ToC from the file toc.ncx (which is in navMap). However, if the toc.ncx is not present, the TOC menu is populated by the Spine listing in the OPF.

When an OPF-spine item is not listed in the TOC.ncx, the Kobo CMS will create a listing for it using the filename or the opening words from the section. This listing will be displayed to the user in the TOC Menu across all reading platforms. This process may be removed in a future release. ePubs that use a nav.html TOC will not be impacted.

**For ePub 3.0**, Kobo platforms will read the ToC from the ToC table in the nav.html file. When a ToC table is not present, the next available table will be used. If the nav.html is not present, it will populate the ToC with the toc.ncx. If the toc.ncx is not present, it will populate the ToC with the spine listing in the OPF.


Edit: I generated two kepubs from an epub3 with a complete and incomplete ToC in both the nav.xhtml and toc.ncx files. I did not notice any issue with page counts in the non-listed files as compared to the version with the "complete" ToCs.

[Cyfranek]

I can't see any converted kepub files in my Aura H2O (firmware 4.5.9587) as well. Converted under Windows 10 using both 32bit and 64bit curren versions. This free e-book for example: http://zajdel.art.pl/publikacje/zajd...antologia.epub

[geek1011]

Originally Posted by Cyfranek

I can't see any converted kepub files in my Aura H2O (firmware 4.5.9587) as well. Converted under Windows 10 using both 32bit and 64bit curren versions. This free e-book for example: http://zajdel.art.pl/publikacje/zajd...antologia.epub

That's unusual. It seems to be a windows issue, because all my books converted without an issue on linux. I will be away for the next week, but when I come back, I will look more into this.

[geek1011]

If anyone has any solid ideas, please feel free to post them here, or open a Pull Request on GitHub. Some places to start mightbe modyfing the generated kepub's TOC. Also, if it is missing a container.xml, please tell me. I have had quite a few instances of missing container.xml s when converting on windows. Also, try converting with the linux version through bash on windows.

Sorry for the inconvenience on windows so far, I will fix this as soon as possible (starting next week).

[geek1011]

And if anyone uses Linux, to build this, just install golang, set your GOPATH env variable to a empty folder in your HOME, type 'go get github.com/geek1011/kepubify', and then you can modify the code. To build it, cd to $GOPATH/github.com/geek1011/kepubify and run 'make'. The output will be in '$GOPATH/github.com/geek1011/kepubify/build/kepubify'.

Sent from my XT1527 using Tapatalk

[geek1011]

I also have another tool I am working on, which I have tested the features so far: https://github.com/geek1011/epubtool. It can pack, unpack, and validate epubs so far, and it may be useful when testing kepubify. I have tested it on Linux.

Example usage:
epubtool unpack /path/to/book.epub
epubtool pack /path/to/epub
epubtool validate /path/to/packed/book.epub

Sent from my XT1527 using Tapatalk

[volpo]

Just wondering...is the 32bit version supposed to work with Windows XP? It would not work here. The error message says "...not a valid Win32 application"

(And yes, I know that I am a Luddite)

[rashkae]

Originally Posted by DNSB

Edit: I generated two kepubs from an epub3 with a complete and incomplete ToC in both the nav.xhtml and toc.ncx files. I did not notice any issue with page counts in the non-listed files as compared to the version with the "complete" ToCs.

Ah.. .I've never tested with Epub3, only 2. I did not expect it to make quite that much of a difference, but I should have clarified in my earlier post.

As for the glitchiness I mentioned with epub, it's the search that doesn't work. The search results are unable to 'jump' to the any results that reside in a file not in the ToC.

For testing of Kepub, the Non-toc files have to be inter-spaced with toc listed files. You will not notice the behaviour if there is only a single Toc list for the first file, or first half of book even. Also, you have to display progress for the whole book. There is no issue with Book progress per chapter, other than the little chart of chapter bar graph being off on current reading position.

[geek1011]

Originally Posted by volpo

Just wondering...is the 32bit version supposed to work with Windows XP? It would not work here. The error message says "...not a valid Win32 application"

(And yes, I know that I am a Luddite)

Nope. Only Windows 7 and up.

Sent from my XT1527 using Tapatalk