[Device Plugin] Kobo Touch Extended Driver

[Leonatus]

Originally Posted by jgoguen

So, in the ZIP file, only the plugin code files should be there. The folder named KoboTouchExtended is where everything else goes.

That's what I'm seeing. The more I'm brooding, the more probable appears that I have committed an error in installing the plugin. But where it is, I don't see, and I don't have the least idea. I followed the instructions as assiduously as I could.

[OverHaze]

Kobo Aura HD here using Mac OSX. Everything seems to be working great!

[jgoguen]

If you installed the plugin from within calibre, you couldn't have installed it wrong. Calibre makes it literally one-click simple

Here's a portion of my directory tree starting at the calibre plugins directory (where KoboTouchExtended.zip resides). Hopefully this helps you discover any errors.

• calibre/plugins/
  • KoboTouchExtended/
    • hyph.dic
    • reference.kepub.epub
  • KoboTouchExtended.zip

Since you're using Windows, make sure you've configured Windows to always show file extensions! Many of my problems in Windows regarding file names and locations have been solved simply by undoing Microsoft's errors in judgement.

[Thalinor]

Originally Posted by BobC

Some of the Kobo books use "kobo-android.js" rather than "kobo.js". I don't know if the driver will handle one of these - perhaps jgoguen can confirm.

Have a look at : https://www.mobileread.com/forums/sho...28&postcount=6 for an example. and at https://www.mobileread.com/forums/sho...&postcount=159 with subsequent posts for previous reference to the "android" variant.

BobC

It had no issues for me using a book with kepub.android.js, at least with the last version. The book I used as the reference file originally was a kobo.android.js file and everything was working as well as others have reported here with the same bugs. I ended finding a free book with just kobo.js and used that one instead, which is what I now use as the reference file. There was no noticeable change in how well the plugin worked when using a reference file from a book with kobo.android.js vs the one with kobo.js, at least from what I could tell.

I have to update the plugin today and again, my reference file (book) is no longer one with kobo.android so I can't check if the new version has an issue. Again, just as an FYI, it did not cause problems before having a reference file (book) with kobo.android.js (vs kobo.js); the plugin seemed to just look for a *.js file in the reference book I used and when it copied the kepubs.epubs it created a .js file in each one simply (re)named kobo.js.

[jgoguen]

I look for '.*/?kobo.*\.js', so 'kobo.js', 'kobo-android.js', 'kobo-iphone.js', 'js/kobo-android.js' and other variants are all perfectly acceptable.

[Thalinor]

FYI new version works amazing, thank you!

No transfer errors, covers all generated, bookmarks seem to be working, all chapters seem to be showing up instead of some being skipped, books are showing up in the correct shelf.

Again, thank you!

[jgoguen]

If anyone is interested in testing, v1.3.4 has been pushed to GitHub. It's not tagged yet, but the files are there. There's a few things I want to have verified first:

• Optimization of the function for adding Kobo span tags. Significantly reduces the number of Kobo span tags added, but hopefully doesn't sacrifice the gains made with v1.3.3 in remembering your last location.
• No more removal of lines with only whitespace characters. Some publishers use these "blank" lines as a way to format their books instead of proper CSS rules, so they can't be removed.

There's also some back-end changes, but these are the things that are going to affect people the most. If you encounter problems with either of these things while testing, please open a new bug on Github (details of what I need in a bug report are in the first post of this thread) so I can take a look.

[met67]

Originally Posted by jgoguen

If anyone is interested in testing, v1.3.4 has been pushed to GitHub. It's not tagged yet, but the files are there. There's a few things I want to have verified first:

• Optimization of the function for adding Kobo span tags. Significantly reduces the number of Kobo span tags added, but hopefully doesn't sacrifice the gains made with v1.3.3 in remembering your last location.
• No more removal of lines with only whitespace characters. Some publishers use these "blank" lines as a way to format their books instead of proper CSS rules, so they can't be removed.

There's also some back-end changes, but these are the things that are going to affect people the most. If you encounter problems with either of these things while testing, please open a new bug on Github (details of what I need in a bug report are in the first post of this thread) so I can take a look.

I have tried it and is absolutely great. The best feature is the kobo span tags optimization: a book that in the previous version used to freeze my Aura now works like a charm.

I have only noted a minor glitch with a space added before an existing span, which is common in smallcaps texts faked with a smaller size text (w2e macro uses this trick all the time...).
I've opened a bug for this with an example.

Thanks for your excellent work!

[Leonatus]

Originally Posted by met67

Thanks for your excellent work!

@jgoguen:
The issue didn't leave me quiet, so I took the book completely new from Gutenberg, formatted it with Sigil and converted it with Calibre, and hoops! Now it works completely fine!

I'm really enthusiastic! Thanks so much!

[Mingyar]

@jgoguen

A little question, do you confirm that after each release, we don't need to delete books from Kobo and send them again ?
Just sending them without delete before is suffisant ?

[jgoguen]

That depends. If you haven't started reading the book yet, then you can just re-send the book without deleting it. If you've started reading the book, you'll need to take note of your position, delete the book, re-send it, and then go back to where you were manually. The reason is that I don't guarantee that you'll get the same Kobo IDs at the same locations and the device expects that the IDs are in the same locations. For books you haven't started reading, that's not a problem because the database doesn't have a bookmarked location yet. But for books you've started reading, there is a location stored and it may or may not exist in the new version.

[PeterT]

Doesn't it also depend on where the book is located? I thought from what davidfor has found, if a book is re-uploaded to the main storage and it's size has changed, that is dropped from the database and not re-added, but on the SD card it is dropped and then re-added?


I was wrong

[jgoguen]

I'd have to do some digging (or wait for davidfor to poke in here ) but I'm sure he said a while ago that if the book is already on the device he updates the size stored in the database to avoid problems.

[met67]

Originally Posted by met67

I have only noted a minor glitch with a space added before an existing span, which is common in smallcaps texts faked with a smaller size text (w2e macro uses this trick all the time...).
I've opened a bug for this with an example.

WOW! That was FAST!

Did I already said thank you for your work? ;-)

P.S. I don't want to look as an ungrateful a***ole, I found another (pathological, I'd say) case where the driver modifies the text:
in my TEST6 epub,

<p>This line follows an empty line made with &lt;p&gt;&amp;#160;&lt;/p&gt;.</p>

is changed to

  <p><span class="koboSpan" id="kobo.18.2">This line follows an empty line made with &lt;p&gt;&amp;#160; &lt;/p&gt;.</span></p>

i.e.

This line follows an empty line made with <p>&160;</p>.

is changed to

This line follows an empty line made with <p>&160; </p>.

(note the space between ';' and '<')

Since I couldn't find any practical case where this could be a problem, I won't open a new bug, but I wanted to let you know anyway.

[jgoguen]

Originally Posted by met67

WOW! That was FAST!

That was a simple regex fix really

Originally Posted by met67

Since I couldn't find any practical case where this could be a problem, I won't open a new bug, but I wanted to let you know anyway.

That should be fixed now too. Another simple regex fix, this time something I left in unintentionally.