Convert epub to kepub

[zztush]

I know there are two nice kepub converters in Calibre, Kobo Touch Extended Driver and KePub Outtput Plugin.
They work perfect to me. But I often convert files manually because I don't use Calibre for manage epub files often. I used to change only extention from epub to kepub.epub. I have not much trouble with it but I lost cover images on my kobo. Therefore I add a step for cover image.

How to indicate cover images in content.opt file.
1)epub (epub2)
epub use metadata to identify cover image. It requires two steps, examples are as follows.

#metadata
<meta name="cover" content="cover-id" />
#manifest
<item id="cover-id" href="cover.jpeg" media-type="image/jpeg" />

2)kepub.epub (epub3)
kepub doesn't use metadata any more. It only uses properties="cover-image". Example is shown below.

#manifest
<item properties="cover-image" id="ci" href="cover.jpg" media-type="image/jpeg" />

I convert epub files to kepub.epub by three steps as follows.
1) Open epub file by winzip, 7-Zip or Sigil. And open the content.opt file.
2) Identify the cover image item in manifest. Add properties="cover-image" in it as shown above.
3) Save it and Change the extention from epub to kepub.epub.

I don't have much trouble so far. Do you have any suggestions to convert files to kepub.epub manually? Thank you very much in advance.

[davidfor]

You have the easy bits. The extended driver and output plugin also change the code in the epub. Without these changes, bookmarking and reading positions don't work. When you reopen a book, it will always open to either the start of the book, or the start of the chapter you were reading.

The changes needed are to wrap a span around each sentence. The span has a particular class and a unique id. The spans do not affect the display of the book, but make the positioning system work. You can look at a book that has been converted, or a purchased kepub without DRM to see what is done.

[zztush]

Thanks davidfor.

Interesting things happen to me. As I haven't wrap a span around each sentence, English books forget their bookmarks and last page after reopen them. But Japanese books work very good and they keep their bookmarks and last pages even after reopen them.

I attach sample files of both English and Japanese. They have been just modified properties="cover-image" in content.opt from original files. And I just have changed their extentions from .epub to .kepub.epub.

[davidfor]

The reading position is based on the current internal file plus the id of the span that includes the text at the start of the screen. If there is no span and hence no id, the kepub will usually reopen to the start of the chapter.

I haven't put this on my Kobo, but from a very quick look, the Japanese book appears to be one page per internal file. Which is effectively one page per chapter. Hence, it will appear to remember the correct page. Using the maximum font size. line spacing and margins, should push the text over multiple screens. If that happens, it should open to the beginning of the chapter rather than later in it.

[Jellby]

Originally Posted by davidfor

The spans do not affect the display of the book, but make the positioning system work.

Unless there is already some CSS like this:

p span { font-weight: bold; }

I guess?

[zztush]

Thanks davidfor.

Japanese kepub.epub files show bookmarks and last page after reopen the files, even when they have mutiple pages in a chapter. We can confirm it with the attached file in this thread before.

[davidfor]

Originally Posted by zztush

Japanese kepub.epub files show bookmarks and last page after reopen the files, even when they have mutiple pages in a chapter. We can confirm it with the attached file in this thread before.

I've put the book onto my Glo, and partly works.

If I make the font big enough so that some chapters goes over several pages, then yes, it does remember the correct page. But, when I powered off and back on, it opened to the start of the chapter.

When I marked text and tried to save it as a bookmark, it didn't. The highlight disappeared and was not listed in the annotations list.

When I tapped the top right corner on the second page of a chapter, the dog ear was shown and remembered in the annotations list. As I moved around the book, it stayed there. When I closed and reopened the book, it moved to the first page of the chapter. Then it moved back to where I put it. Again, after a power off, it moved to the start of the chapter and stayed there.

For curiosity, I had a look at the database. There isn't enough information being stored to go back to the correct position or put the bookmark in the right place. From that, it has kept the correct position in memory, but as it is not in the database, restoring the position and bookmark can't be done properly.

From all this, it isn't working properly. And I suspect the only reason it is working as well as it is, is because the chapters are so short.

[anavin]

Originally Posted by Jellby

Unless there is already some CSS like this:

p span { font-weight: bold; }

I guess?

Now you mentioned it...

I do encounter this problem, practically all of my vertical layout books, since some of texts need to be "tate-chu-yoko":

html { -epub-writing-mode: vertical-rl; }
.tcy { -epub-text-combine: horizontal; }

<p>今天是<span class="tcy">9</span>月<span class="tcy">24</span>日</p>

With the current version Kobo Touch Extended Driver, my books are converted to:

<p>
  <span class="koboSpan" id="x">今天是</span>
  <span class="tcy">
    <span class="koboSpan" id="x">9</span>
  </span>
  <span class="koboSpan" id="x">月</span>
  <span class="tcy">
    <span class="koboSpan" id="x">24</span>
  </span>
  <span class="koboSpan" id="x">日</span>
</p>

and the "tcy" styles are all gone on my Kobo Glo.

Currently I just hack the container.py to make it skipping all <span> and <a>:

    def __append_kobo_spans_from_text(self, node, text):
        if node.tag.endswith('span') or node.tag.endswith('a'):
            return False
    ...

I don't think it solves the problem though -- for example, I've seen *some particular publisher* (cough * MediaFactory * cough) made books like this:

.c1 { ... }
.c2 { ... }
.c3 { ... }
.c4 { ... }
...

<p class="c1"><span class="c2">...</span></p>
<p class="c3"><span class="c4">...</span></p>
...

And my hacked container.py wouldn't add any koboSpan on it. (fortunately the book was already a kepub, so I don't get too many problems for now.)

Any suggestions?

[zztush]

Thank you very much davidfor.

It is totally doesn't work even in Japanese books. I have checked other Japanese books and confirmed it. All of my kepub.epub books, which work properly in terms of bookmarks and last pages, are converted by certain converters like Kobo Touch Extended Driver and KePub Outtput Plugin. They wrap a span around each sentence.

The reasons why I mistook it were as follows
1) I have both automatically converted and manually converted kepubs together in my kobo.
2) I don't check the difference between sleep, power off and home position. It totally doesn't work after power off.
3) Chapters are so short.
4) Many Japanese sites recommend to change extensions from epub to kepub.epub manually for Japanese books without any attention about bookmarks.

I will never change the extension from epub to kepub.epub manually. Thank you very much.

[j.p.s]

Originally Posted by davidfor

The changes needed are to wrap a span around each sentence. The span has a particular class and a unique id. The spans do not affect the display of the book, but make the positioning system work. You can look at a book that has been converted, or a purchased kepub without DRM to see what is done.

If someone were willing to tolerate, or even preferred, the coarser granularity, could this be done with paragraphs instead of sentences?

[davidfor]

Originally Posted by j.p.s

If someone were willing to tolerate, or even preferred, the coarser granularity, could this be done with paragraphs instead of sentences?

Yes, that can work. I remember creating a small kepubs like that and I think that's what the early versions of the extended driver did. From memory, there are problems with it. I think it is OK as long as there are no nested tags. And there might be an issue with longer paragraphs. Or paragraphs that go over more than one screen.

[cybmole]

are these drivers expected to work with the new Kobo H2O , or will new versions be needed ?

[beedaddy]

Originally Posted by cybmole

are these drivers expected to work with the new Kobo H2O , or will new versions be needed ?

I'm pretty sure the kobo touch extended plugin will work with the H2O (not yet tested).
What might not work is the H2O-specific css (kobo_extra_AURAH2O.css) file. I modified the code locally (just out of curiosity) in order to check for that file, but, as I said, didn't test it yet.

[cybmole]

Originally Posted by beedaddy

I'm pretty sure the kobo touch extended plugin will work with the H2O (not yet tested).
What might not work is the H2O-specific css (kobo_extra_AURAH2O.css) file. I modified the code locally (just out of curiosity) in order to check for that file, but, as I said, didn't test it yet.

thanks, can you post an update after testing please, as it's a big factor in whether I order one.

[davidfor]

Originally Posted by cybmole

thanks, can you post an update after testing please, as it's a big factor in whether I order one.

calibre was updated last week to support the Aura H2O. Well, it was update a month ago, but I made a mistake that was only noticed when tried a H2O.

The extended driver and output plugin will both work with the H2O unchanged. The only problem at the moment is the one that beedaddy mentioned. But, it will work with the default name of "kobo_extra.css".