book loop back at the end of chapter about calibre-kobo-driver HOT 12 CLOSED

Ok in the meantime I have made some test. When I upload the file something is messed in the xhtml file and for this reason the books presents that problem I was mentioning in my previous comment. I try to post it what is inserted:

As you can see that CDATA part is something which should not be there and I believe it is the piece which bring all my problem.

Regards,

Maurizio.

from calibre-kobo-driver.

Regarding the "Cover loop" issue, it seems the same problem I've pointed out in another issue, where the chapters go in random order. I don't think it's coming from how the kepub is formatted. This all stems from the code adding entries referring to the single TOC entries in the Kobo.sqlite database. As jgoguen told me to, try to use the "no_database" branch of the code and the thing should be solved.
As for the other information, it seems quite interesting...

from calibre-kobo-driver.

@mauriziofantino Can you try the no-database branch and see if the cover loop issue still exists for you after removing the book from your Kobo device and re-adding it? I will see if I can get one of my purchased books to re-download, I was having problems with that a couple weeks ago. I will most likely need a book for testing; do you have a book purchased from Kobo with the digital restrictions management stripped (or that was sold without DRM) and not changed/converted in any other way that you would be willing to send me? I'll also take the one you modified manually, but I will need a decrypted book as close to its original state as possible. I've added my email address to my public profile page here.

It should be possible to rebuild the kepub structure, but if you don't mind I'd like you to make a separate bug report for that. The cover loop issue I hope will be fixed with bug #5. Ideally I'd like to try to keep one issue per bug report and I think it'll be the bookmark issue for this one.

from calibre-kobo-driver.

The CDATA blocks usually indicate character data (CDATA means "character
data") within a XML tag that must be displayed as-is and not parsed as XML.
There are valid reasons why that might be added. I'll take a look at the
results of conversions as I work through other bugs, see if I notice it and
try to figure out why it's happening.

As a note, if a tag has the string "" as its text,
what you should see displayed on screen is "Hello, World!". Is that the
case for you or are you seeing the entire CDATA block as well? Hopefully
the text shows properly :)

Joel Goguen
Email: [email protected]
Web: http://www.jgoguen.ca/

On 2013-01-29, at 15:49, mauriziofantino [email protected] wrote:

I am using the no-database branch... and i am having the issue with it. I
dunno if the problem is related to this or not but if I check the structure
of the file sideloaded on the kobo glo before the
tag I the conversion put this strange string: ;![CDATA[

As far as the other information a quick update: I have taken on of the book
and rebuild the structure of an origianl kepub. I have kept the page style
of the epub as it was, but also added the kobo.css (which keep a proper
formatting which allows to have no problem with the bookmarks) and the
kobo.js (which has a script for the bookmark evaluation) and manually
corrected each header of each xhtml file in the text folder. What I can
tell you is that the epub so correct is perfect. Any problem with the
bookmark, page style well formatted. No error in the page formatting (by
just changing the extension file sometimes it happened to me that to have
at the bottom of the page half row in height and then the same row repeted
in the following page, problem that now I have not anymore).

I did nothing straordinary, and I can share it with you. The problem is
that I did it manually cause I can program in C, but not in python (not yet
:-P ) and I have no expertise in calibre plugins.

If you want me I can share the result of the upload, the same book after my
header correction and one of the original (free) kepub which I used as
example.

Send me an email to [email protected] and I will send to you the
books.

Good good work I really see the potential to have an epub almost identical
to a kepub on my kobo glo without doing anything than simply press a
button!!!

Maurizio

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/6#issuecomment-12853988.

from calibre-kobo-driver.

@jgoguen Errata Corrige I was not using the no-database branch.

@giorgio130 I have read your post here http://forum.simplicissimus.it/kobo/calibre-driver-per-kobo-con-funzioni-aggiuntive-%28kepub%29/ Good Spread the word.

from calibre-kobo-driver.

Can you see if this is fixed now for you? This issue is only dealing with the book looping on the cover page, I've created bug #7 for investigating the rebuild of the kepub and adding additional files.

from calibre-kobo-driver.

The problem of the cover loop seems to be fixed. I have tried with 5, 6 books and I had no problem with them. One strange thing is that for all of them but one the cover was correctly uploaded on my kobo. For one I got the blank cover with the title. To get the cover of this last book I had to plug back my kobo and re-sync the meta data, unplug it and here there was the cover. I have tried several times this procedure (also using the modify epub calibre plugin to correct cover and metadata issues) but I got always the same behavior.

Mauri

from calibre-kobo-driver.

I have tried the no-database branch... Should I have used the master one?

from calibre-kobo-driver.

Can you try with the master branch? That's where the database code is that was causing problems. It's good that you tried with no-database as well, that validates that the no-database branch is working properly.

The examples weren't bad. The covers are based on what's defined in the ePub file itself; if there's a tag with id="cover", I add the properties="cover-image" which is what tells the Kobo to show that as a cover image. There are some books, even professional books direct from major publishers, without any cover specified at all; for these, when using calibre and this plugin, what happens is:

• The ePub file is converted, no cover image is marked since none exists.
• The ePub file and cover image is uploaded to the appropriate places on the Kobo device.
• The database is updated with the proper image ID.
• After ejecting the Kobo device, it processes the ePub file, finds no cover image, displays the generic cover. This causes the image ID field (among others) to be emptied.
• Plugging the Kobo device back into calibre causes calibre to update the metadata, including re-setting the image ID.

from calibre-kobo-driver.

ok I tested the master and it works as the no-database. Which branch shall we use for testing in order to help you with the development?

Thanks for the explanation on the id="cover", it might be boring but I belive this can be easily fxed by editing the book with Sigil or simply by doing the procedure you mentioned to resynch the metadata.

I have also noticed that the original kepub they also have the class KoboSpan before the id="kobo.x.y" in the form . The converted epub they are missing the class part. Do you know the scope of this missing part?

Maurizio

from calibre-kobo-driver.

I'm pretty sure you actually can't use Sigil for adding the cover-image property. That is actually not valid according to the ePub specification, so Sigil warns you about a validation issue. I'm not sure why Kobo decided to require a non-standard attribute, but readers simply ignore the extra attribute so it's not as bad as it could be. It's only validating applications (like Sigil) that are unhappy.

Adding the koboSpan class is something I'm dealing with in bug #7, since it wasn't relevant to the cover page loop issue. Now that this bug is fixed, I'll start on #7 which will include the koboSpan class.

For what branch to use, it depends. For normal day-to-day use, definitely use the no-database branch. The database code is currently interesting, but has no lasting effect while the device is still processing new books. Although as we've seen, getting the database entries wrong can really cause problems. As a tester, which branch to use depends on what code each bug touches. For any bug that touches the database code (like #5 and this one) the master branch must be used. For bugs that don't touch the database code, both branches must be tested.

from calibre-kobo-driver.

The "koboSpan" class has been added to both branches.

from calibre-kobo-driver.