[Conversion Output] KePub Output Plugin

[davidfor]

Originally Posted by jackie_w

Firstly, I don't think there's anything wrong with the HTML markup for footnotes in this book.

I think what you're seeing may be yet another example of the problems that can occur when there isn't a one-to-one correlation between the HTML files and the TOC entries. This book is doubly "problematic". Some HTML files don't have a TOC entry at all. Other HTML files have multiple TOC entries.

I corrected this in the scrambled copy you posted and now all footnotes pop-up as expected.

I didn't think of that. But, generating the ToC just for the files, rather than the headings, and they all work fine.

[tartanpion]

Ok I have merged the part45.html and generated a new toc for files with calibre editor and all the footnotes seem to have the same pop-up behavior. I don't have see anywhere that the toc could disturb the footnote/endnote with kepub. Can this be "automatized" with the plugin ?

[davidfor]

Originally Posted by tartanpion

Ok I have merged the part45.html and generated a new toc for files with calibre editor and all the footnotes seem to have the same pop-up behavior. I don't have see anywhere that the toc could disturb the footnote/endnote with kepub.

@DNSB gave you a link to the closest thing that Kobo publishes as specs for kepubs. The book didn't meet those specs. Therefore, you cannot assume anything will work properly.

Can this be "automatized" with the plugin ?

You can have the conversion either split the internal files at different spots, or, generate a the ToC in a different way. You would need to look at the book to decide which is best. My quick and dirty test was to use the editor to remove the current ToC and generate one for each file in the book. An alternative would have been to generate the ToC for the h2 tags. Though I don't know if that would have gotten everything.

[giddie]

I hope this isn't too far off-topic: does anyone know if there's a trick to convince the Calibre Editor to open a KEPUB file as an ePub? When I buy books from Kobo, I like to keep them in KEPUB format, so that I know it's an "official" KEPUB, and so that the output plugin simply copies the existing KEPUB directly to the device.

However, in order to do any editing of the file, I have to change the file's extension before I can edit it, then change it back. This is a bit of a pain. Any ideas?

[davidfor]

Originally Posted by giddie

I hope this isn't too far off-topic: does anyone know if there's a trick to convince the Calibre Editor to open a KEPUB file as an ePub? When I buy books from Kobo, I like to keep them in KEPUB format, so that I know it's an "official" KEPUB, and so that the output plugin simply copies the existing KEPUB directly to the device.

However, in order to do any editing of the file, I have to change the file's extension before I can edit it, then change it back. This is a bit of a pain. Any ideas?

The simplest way to do it is to add the kepub as an epub. If you use the extended driver, it will send the book unchanged but fix the extension.

Otherwise, if you are willing to run calibre from source, I can tell you what changes to make to the source to edit kepubs.

[jiembe]

Originally Posted by davidfor

The simplest way to do it is to add the kepub as an epub. If you use the extended driver, it will send the book unchanged but fix the extension.

Oops. Can you explain those one: "add... as" and "use the... driver".

[davidfor]

Originally Posted by jiembe

Oops. Can you explain those one: "add... as" and "use the... driver".

Sorry, I haven't been exactly how to answer these, as they feel to be both basic questions and complex at the same time And I hadn't noticed that this came from a different person to the one I had responded to.

"add the kepub as an epub":

You have to add the book to calibre. There are several ways to do this (press the add button, drag-and-drop, auto add, using the command line tools, probably others). But, it basically means telling calibre about the copy of the book in it's current format. Calibre uses the extension work out the format of the book. If you have a kepub from somewhere, it needs to have the extension "kepub" for calibre to see it as a kepub. If you use the extension "epub", it will be treated as an epub. As a kepub is actually an epub with some specific code added to it, you can change the extension to "epub" and calibre will just treat it as an epub.

"use the extended driver"
That is exactly what it means. Calibre comes with a built-in KoboTouch driver. This is used to communicate with Kobo devices. The KoboTouchExtended driver (the "extended driver") is an plugin that can be added to calibre and adds function to the built-in driver. The main one is an on-the-fly transformation of epubs to kepubs when an epub is sent to the device. It is generally used as an alternative to the Kepub Output plugin (which this thread is for) to create kepubs without adding them to the calibre library.

The KoboTouch driver cans send kepubs to the device. If you have them in the calibre library, you do not need the extended driver. But, kepubs are not useful anywhere else. If you do have kepubs from another source, you can add them to calibre as kepubs. Or, you can change the extension and add them as epubs. This allows the books to be used elsewhere. But, if you want them sent to a Kobo device as a kepub, you need to use the extended driver. When the book is sent to the device, the extended driver will check if the kepub code is in the book. If it is, the book will be sent as kepub without any changes. If they are not there, the extended driver will do the work to create the kepub.

The decision on what to do depends on what format your books are coming in, and how you want to use them. Other from Kobo, books don't normally come as kepubs. So, most add the format they get them in, and either convert to kepub, or send to the device using extended driver. Or just use the epub format.

[jiembe]

If you do have kepubs from another source, you can add them to calibre as kepubs. Or, you can change the extension and add them as epubs.

I didn't knew that.

Thank you for the explanation and even more for Calibre which is really really a great program.

It is said about this plugin that it is better to install KePub Metadata Reader and
KePub Metadata Writer. Even if I never done that, the KePub conversion works well. Is it still a best to install those 2 plugins and why?

Last, when the kepub is created the cover page revert to lang="en" even if I put lang="fr". Just curious to know why.

[davidfor]

Originally Posted by jiembe

I didn't knew that.

Thank you for the explanation and even more for Calibre which is really really a great program.

It is said about this plugin that it is better to install KePub Metadata Reader and
KePub Metadata Writer. Even if I never done that, the KePub conversion works well. Is it still a best to install those 2 plugins and why?

Those two plugins are used to read and write the metadata to the books. Without these, calibre cannot fetch the metadata from or update the metadata in kepubs. If you are storing kepubs in the calibre library, you should install these two plugins.

Last, when the kepub is created the cover page revert to lang="en" even if I put lang="fr". Just curious to know why.

The language is hardcoded in the template for the cover. But, it probably doesn't matter. There isn't anything on it that would use the language.

[giddie]

Originally Posted by davidfor

The simplest way to do it is to add the kepub as an epub. If you use the extended driver, it will send the book unchanged but fix the extension.

Otherwise, if you are willing to run calibre from source, I can tell you what changes to make to the source to edit kepubs.

Thanks; I guess the official solution is to store kepubs as epubs then. Can the extended driver be relied on to always do the right thing? It's not possible it might accidentally add duplicate spans due to a false-negative?

[JSWolf]

Originally Posted by giddie

Thanks; I guess the official solution is to store kepubs as epubs then. Can the extended driver be relied on to always do the right thing? It's not possible it might accidentally add duplicate spans due to a false-negative?

Either you trust the trust the extended driver or you read ePub.

[davidfor]

Originally Posted by giddie

Thanks; I guess the official solution is to store kepubs as epubs then. Can the extended driver be relied on to always do the right thing? It's not possible it might accidentally add duplicate spans due to a false-negative?

The Kepub output plugin basically just uses the ePub output plugin to do a conversion and then applies the spans. That code is largely shared with the extended driver. If one doesn't do the spans correctly, the other won't as well.

[giddie]

Originally Posted by davidfor

The Kepub output plugin basically just uses the ePub output plugin to do a conversion and then applies the spans. That code is largely shared with the extended driver. If one doesn't do the spans correctly, the other won't as well.

Sorry, I was referring more to whether it would always detect that an epub is in fact already a kepub (with spans etc...) and simply send it to the device as-is. Is it safe to rely on its ability to detect that situation as opposed to keeping a copy with the kepub extension in the Calibre library?

[davidfor]

Originally Posted by giddie

Sorry, I was referring more to whether it would always detect that an epub is in fact already a kepub (with spans etc...) and simply send it to the device as-is. Is it safe to rely on its ability to detect that situation as opposed to keeping a copy with the kepub extension in the Calibre library?

The extended driver checks each internal file for the spans. If there is at least one, then the file is skipped. If none are change, then the whole file is assumed to be a kepub and sent as such.

It wouldn't be hard to fool the extended driver by adding one span with the appropriate class. But, overall, it should be safe.

[jgoguen]

Originally Posted by giddie

Thanks; I guess the official solution is to store kepubs as epubs then.

I've tried to be explicit about the importance of keeping a non-KePub format in your calibre library. The KePub format isn't documented so what I have is an attempt at reverse-engineering the rules and details based on existing books. The only time it would be OK to have only the KePub format for a book is if you downloaded the KePub directly from Kobo.

Originally Posted by giddie

Can the extended driver be relied on to always do the right thing? It's not possible it might accidentally add duplicate spans due to a false-negative?

I would be surprised if duplicate spans would get added. I search each HTML file for any node which has class 'koboSpan' or which has an id attribute beginning with 'kobo.'; if any single HTML element is found with either of those conditions true, I assume the file is already converted and skip it.


Like davidfor said, it would not be difficult to fool this plugin (or the extended driver, the conversion code is shared between them). But that would prevent adding spans. To fool it into adding duplicate spans you would need to preprocess all content files to change the class and id attributes, then run the conversion, then post-process the file to restore the original class and id attributes. And at that point it's not a bug in the conversion that duplicate spans get added


What would be possible is if Kobo changes the KePub format (it's their own format officially not implemented anywhere else, they can change it anytime they want for any reason) and that update completely changes both the class and id attributes or uses a tag other than "span". But I doubt that's likely to happen.