Touch .kepub.epub

[mapline]

David, I too would like to thank you for cover tip. Works a treat. (KT on v 2.3.1)
Now I just I change epubs with calibre "search & replace changes" and then use dsandrei modified "modify ePub" then for covers to shows your mod.
I know some prefer the epub format but I like the Kepub chapter page numbering ( as I read by chapter no whole book).
If you can make it an option of your driver to combine steps it would be great!
Regards from the cold and snowy UK
Michael

[eXistenZ]

Hi someone can help me to install Joel Goguen's extension on mac?
I followed the istructions on github and created the KoboTouchExtended.zip file.
The last point "Shut down Calibre and run calibre-customize -b /path/to/calibre-kobo-driver" is not so clear to me (my fault of course) someone can point me to the right path to the kobo driver?

Thank you

[giorgio130]

Originally Posted by eXistenZ

Hi someone can help me to install Joel Goguen's extension on mac?
I followed the istructions on github and created the KoboTouchExtended.zip file.
The last point "Shut down Calibre and run calibre-customize -b /path/to/calibre-kobo-driver" is not so clear to me (my fault of course) someone can point me to the right path to the kobo driver?

Thank you

This is not really clear on the readme file, as those are two different alternatives. If you create the zip with those file then proceed to install as any other calibre plugin, just open preferences, then plugins, install... etc.

[eXistenZ]

Originally Posted by giorgio130

This is not really clear on the readme file, as those are two different alternatives. If you create the zip with those file then proceed to install as any other calibre plugin, just open preferences, then plugins, install... etc.

Thank you it was too easy

Now I'm testing it, but generated kepus are unreadable, if I go to a chapter using the TOC, and turn pages till the end of it the next turn don't bring me to the next chapter but to the first page of the first chapter, in other words without using the TOC menu I remain stuck in a loop in the first chapter. I'll try with other ebooks but it's happened to 6 of them yet.

Some one else experienced this?

[giorgio130]

Originally Posted by eXistenZ

Thank you it was too easy

Now I'm testing it, but generated kepus are unreadable, if I go to a chapter using the TOC, and turn pages till the end of it the next turn don't bring me to the next chapter but to the first page of the first chapter, in other words without using the TOC menu I remain stuck in a loop in the first chapter. I'll try with other ebooks but it's happened to 6 of them yet.

Some one else experienced this?

Yes, that's a known bug, you should use the code from the "no_database" branch in order to avoid it.

[jgoguen]

Originally Posted by fx3000se

I played around with Joel's plugin this weekend. Any epub-book (.kepub) sent to my Kobo Mini had problems remembering the last page read

Disabling the plugin and deleting/re-sending the epub solved the issue ...

Anybody else?

I believe there is a bug submitted that, once I fix it, will address this. There may need to be some changes to how the Kobo tags get added.

Because of the issues with the database code (which, BTW, isn't really useful for anything until I sort out how to make the Kobo devices not do their initial processing) the no-database branch is default when you visit the repository. There is an issue tracker there for any problems you may find.

@davidfor: Would you like me to work on merging the kepub code I have with the main KoboTouch driver and submit a patch? I'd want to finish the known issues first, and I could make two options; one for "use .kepub.epub" that automatically updates the file name but doesn't touch the files themselves, and one for "enable all the extra stuff" that tweaks the book files and implies forcing .kepub.epub.

[DomesticExtremis]

I've been tinkering with this - just doing the change of extension to .kepub.epub and then tweaking the contents.opf to add the cover-image property as described in post #15.

It kind of works for me, thought the cover page doesn't always display properly - I have to turn one page forward then one back. I haave a hidden heading in this page so that it gets added to the toc, and when displayed as a kepub I think the viewing are isn't quite as large, so it somehow gets the display wrong.(if that makes any sense).

I'm using a Kobo Mini with fw 2.3.1. My image is originally 600x800 but the cover page is coded to display it as 548 x 760 using the magic incantation for svg tags I saw posted elsewhere on this forum.

the real win comes with footnotes - the book I have has these with superscripted links to endnotes at the end of each chapter. In epub form, it is difficult even to get the link to work, but in kepub, they work pretty reliably and it gives you a popup preview (usually big enough to see the whole footnote).
Touching on 'see more' takes you to the end of the chapter to see to footnote proper. The 'back' links work correctly as well, taking you to precisely where the original link was, rather than some random point prior to that when in epub mode.

So for a book with footnotes, this is definitely worth doing.

It would be nice to get the cover image working seamlessly though.
It does display OK on the 'home' page as well as in the library, so
I'm guessing it has been parsed into the .kobo directory, I guess the
problem might lie in my cover page html or the image resizing.

[DomesticExtremis]

BTW the properties="cover-image" attribute causes Sigil's FlightCrew checker to raise a warning (Sigil v 0.6.2).

[davidfor]

Originally Posted by jgoguen

I believe there is a bug submitted that, once I fix it, will address this. There may need to be some changes to how the Kobo tags get added.

Because of the issues with the database code (which, BTW, isn't really useful for anything until I sort out how to make the Kobo devices not do their initial processing) the no-database branch is default when you visit the repository. There is an issue tracker there for any problems you may find.

What do you want to stop? If you are trying to stop all the scanning, that isn't a good idea. What about all the other book types, or if books are added outside calibre.

If you are just trying to prevent the new .kepub.epub from being scanned and reprocessed, then it should be in the timestamps and file sizes. The last change I made to the driver was to update the files size when resending a book. This prevented the replaced book from being removed when the processing was done.

It might be different for kepubs. I can see an entry in the Event table for all downloaded kepubs that isn't there for sideloaded books. Look for EventType=4.

But, when I have tested the database code, it didn't create all the rows. All the ContentType=6 and 9 seem to be there, but not the 899. The last test was with code I downloaded yesterday, so it should be the latest.

If you continue with the database updates, you should also consider epub3. The TOC is no longer in a separate file but inside the OPF. Kobo support for epub3 is reasonably good and getting better. An extra thing to try is adding the epub3 statement to the OPF for series info. That might get read even on an epub2.

@davidfor: Would you like me to work on merging the kepub code I have with the main KoboTouch driver and submit a patch? I'd want to finish the known issues first, and I could make two options; one for "use .kepub.epub" that automatically updates the file name but doesn't touch the files themselves, and one for "enable all the extra stuff" that tweaks the book files and implies forcing .kepub.epub.

I still haven't completely made up my mind about adding this. If I do, I'll do the merge. I need to be happy it all works. And the options are a problem I need to look at. There are already a lot, and there is another I am thinking about. Plus, separating the file naming from the file massaging is pointless. One thing, I won't be doing the database changes.

[davidfor]

Originally Posted by DomesticExtremis

BTW the properties="cover-image" attribute causes Sigil's FlightCrew checker to raise a warning (Sigil v 0.6.2).

That is to be expected as it is not part of the epub2 specification. I know I tried that, but I don't remember if Sigil removed it when saving.

[DomesticExtremis]

No, it is kept in place.

[jgoguen]

Originally Posted by davidfor

What do you want to stop? If you are trying to stop all the scanning, that isn't a good idea. What about all the other book types, or if books are added outside calibre.

If you are just trying to prevent the new .kepub.epub from being scanned and reprocessed, then it should be in the timestamps and file sizes. The last change I made to the driver was to update the files size when resending a book. This prevented the replaced book from being removed when the processing was done.

It might be different for kepubs. I can see an entry in the Event table for all downloaded kepubs that isn't there for sideloaded books. Look for EventType=4.

Yes, I just want to stop processing of the books that my driver uploads, anything else added in any other way should be processed as usual.

Originally Posted by davidfor

But, when I have tested the database code, it didn't create all the rows. All the ContentType=6 and 9 seem to be there, but not the 899. The last test was with code I downloaded yesterday, so it should be the latest.

There was a problem I fixed late last night (from my UTC-4 perspective) that resulted in the 899 rows being skipped and the 9 rows being added incorrectly.

Originally Posted by davidfor

If you continue with the database updates, you should also consider epub3. The TOC is no longer in a separate file but inside the OPF. Kobo support for epub3 is reasonably good and getting better. An extra thing to try is adding the epub3 statement to the OPF for series info. That might get read even on an epub2.

Thanks for the info. My motivation for the DB code is to set series information on the initial add, without having to plug the Kobo back in for a second pass, so if I can't do that before I run out of ideas I'm considering just removing the database code entirely.

[davidfor]

Originally Posted by jgoguen

Yes, I just want to stop processing of the books that my driver uploads, anything else added in any other way should be processed as usual.


There was a problem I fixed late last night (from my UTC-4 perspective) that resulted in the 899 rows being skipped and the 9 rows being added incorrectly.

OK. I grabbed that and it seems to be working now.

Thanks for the info. My motivation for the DB code is to set series information on the initial add, without having to plug the Kobo back in for a second pass, so if I can't do that before I run out of ideas I'm considering just removing the database code entirely.

I have just had a play and I can't see why they are being reprocessed when. I noticed two things. Firstly, "__UserId" column should be set to "kobo_user" on the ContentType=6 row. The other thing is that a lot of the columns are being set to an empty string when the device sets them to null. It might be one of these that is causing the reprocessing.

Anyway, that is part of why I am not doing this in the driver. I don't completely understand the rules for creating these rows. Plus, they have changed a bit with the firmware.

[mapline]

Hi davidfor and jgoguen
Please don't give up as you seem so close.
Your work is really appreciated by Kepub users.
Many thanks
Michael

[jgoguen]

Originally Posted by mapline

Hi davidfor and jgoguen
Please don't give up as you seem so close.
Your work is really appreciated by Kepub users.
Many thanks
Michael

Thanks for the encouragement! I'm not very active on these forums (I kind of stumbled on this thread while looking for Kobo database schema information), all my activity is over on the Github repository and the issue tracker there. There's a few things, quite annoying, that I'd like to have fixed. There's also two Launchpad bugs (that I'm aware of, 1096410 and 1058912) that are asking for kepub support. I'll be updating at least one of those (probably 1058912) when I'm satisfied with the code, unless davidfor merges things in earlier.

In case you're interested in using the plugin from the Github repository, make sure to use the no-database branch. The master branch has some code to manipulate the Kobo device's SQLite database that is probably going to get ripped out if davidfor's suggestion to use EPUB3 series designations works out. Even if it doesn't work, the database code will probably still get removed anyway since it is more effort than it's worth (especially since Kobo can change the rules at any time) to track down the rules for when various fields get set to specific values. Even ones like page numbers, which may seem obvious, are far from obvious. The end result being that I set the series information in that code, then the Kobo removes it while processing the new book.