[Device Plugin] Kobo Touch Extended Driver

[jgoguen]

Originally Posted by davidfor

But, even with that class defined, aren't all the styles just going to pass through it?

After some digging, it seems "-webkit-text-combine" has only two values (other than the implicit "inherit" available on all inheritable properties): "horizontal" and "none". "none" is the default, "horizontal" is the same as the standard CSS property "text-combine-upright: all" (which is currently the only valid value other than "none" according to the standard; CSS4 includes a "digits" keyword that makes it apply only to digits, e.g. "digits 2" and "digits" are the same, "digits 4" applies to up to 4 consecutive digits).

According to the "text-combine-upright" standard, this breaks across box boundaries; "<p>This is text</p>" could have it applied, but "<p>This is <span>text</span> in a box</p>" would break and user agents should treat it as though "text-combine-upright" were set to "none". That doesn't seem to be always true in practice, at least Chrome attempts to do the intuitive thing and effectively sets the default values as "-webkit-text-combine: inherit" and "text-combine-upright: inherit". Kobo's style declaration seems to be either saying the ACCESS renderer adheres to the standard or is acknowledging that books may be read on devices which do.

So yes, in theory this should be a no-op for most books. But it does have me wondering if I should be trying to make sure that style declaration is present.

[davidfor]

Originally Posted by jgoguen

If it's metadata it may not be this driver. Can you do a few things:

• Remove all problematic books from the device
• Restart calibre in debug mode
• Send one single problematic book to the Kobo, then close calibre (to get the debug log) and restart it normally
• Attach a scrambled copy of the book and the calibre debug log

Based on @jxall's post, the problem is not the driver. It seems to be happening when kepubs are sent from the library. It looks like a problem with the KePub Metadata Writer plugin. It is writing a zero length OPF file when I do a conversion or use the Embed metadata tool. That will happen with the send-to-device if there is a kepub in the library.

[NiLuJe]

@jxall: I vaguely seem to recall that actual processing errors happen *before* the pruning step.

Might be wrong, though .

In any case, looks like @davidfor found the root of the issue .

[mirage]

I'm having the same invisible kepub issues as @jxall and @thatbend in Calibre. In some cases, the kepub won't open at all on the Libra H2O. Certain books give me an "Oops! This document couldn't be opened," error.

kepubify converted epubs work fine, including the ones that give me the "Oops" error. If I disable the KTE driver and the Metadata Writer plugin, then upload files as either epub or kepub, that's mostly fine, too, though I can still get the "Oops" error.

I've been injecting word count data into book subtitles via the Metadata Plugboard feature. So there are related errors with KTE disabled.

I've yet to debug this, but wanted to confirm the same observations as the others and pass along my appreciation for the efforts to figure it out.

[icallaci]

I just noticed that the <br/></p> problem is still occurring with 3.12.11. It happens when a kobo <span> is inserted inside <em></em> tags.

[JSWolf]

Originally Posted by icallaci

I just noticed that the <br/></p> problem is still occurring with 3.12.11. It happens when a kobo <span> is inserted inside <em></em> tags.

How can you tell when KePub isn't working?

[theducks]

Originally Posted by JSWolf

How can you tell when KePub isn't working?

I see this code also.
Jon
the first part is centered, the code breaks the second line, which should ALSO be centered (and styled).

I used the editor to LOOK at the code that was ON the DEVICE file.
the code also ended with

 <p> </p>

[icallaci]

Originally Posted by JSWolf

How can you tell when KePub isn't working?

Because <p class="center">Some text goes here<br/>and more text goes here</p>

turns into <p class="center">Some text goes here<br/></p><p>and more text goes here</p>.

So instead of seeing both lines centered, one on top of the other, you see the top line centered, while the bottom line is left-aligned instead of centered.

[icallaci]

Removed 3.2.11 and reverted to 3.2.9 of the KTE driver, and it behaves correctly.

[jxall]

[ deleted ]

[jgoguen]

Originally Posted by icallaci

Because <p class="center">Some text goes here<br/>and more text goes here</p>

turns into <p class="center">Some text goes here<br/></p><p>and more text goes here</p>.

So instead of seeing both lines centered, one on top of the other, you see the top line centered, while the bottom line is left-aligned instead of centered.

This one is quite strange, since the spans the conversion adds aren't in the markup you're reporting. Please attach a scrambled ePub, a scrambled converted KePub, and the calibre debug log showing the conversion process.

[icallaci]

Originally Posted by jgoguen

This one is quite strange, since the spans the conversion adds aren't in the markup you're reporting. Please attach a scrambled ePub, a scrambled converted KePub, and the calibre debug log showing the conversion process.

Sorry, it was just a quick example to explain the problem to Jon. It wasn't directly copied from the reader. Sorry for the confusion. Going back to 3.2.9 beta fixes the issue.

Here is the original code:

<p class="center"><em>Some text here<br/>And more text here</em></p>

And here is the code as it appears on the Kobo ereader:

<p class="center"><em><span class="koboSpan" id="kobo.3.1">Some text here</span><br/></em></p><em><span class="koboSpan" id="kobo.6.1">And more text here</span></em><p></p>

[NiLuJe]

Good news: the empty OPF thingy is my fault (oops). No idea how I failed to notice it the first time around :/.

https://github.com/jgoguen/calibre-kobo-driver/pull/108 *should* fix it, but I wouldn't mind another pair of eyes on this (especially from people who actually know what they're doing ^^).

[davidfor]

Originally Posted by icallaci

Sorry, it was just a quick example to explain the problem to Jon. It wasn't directly copied from the reader. Sorry for the confusion. Going back to 3.2.9 beta fixes the issue.

Here is the original code:

<p class="center"><em>Some text here<br/>And more text here</em></p>

And here is the code as it appears on the Kobo ereader:

<p class="center"><em><span class="koboSpan" id="kobo.3.1">Some text here</span><br/></em></p><em><span class="koboSpan" id="kobo.6.1">And more text here</span></em><p></p>

Looks like we lost the fix for this. Which was probably my fault as I wasn't using git at the time. I've stopped being lazy and have just created a pull request to put it back in.

[davidfor]

Originally Posted by NiLuJe

Good news: the empty OPF thingy is my fault (oops). No idea how I failed to notice it the first time around :/.

https://github.com/jgoguen/calibre-kobo-driver/pull/108 *should* fix it, but I wouldn't mind another pair of eyes on this (especially from people who actually know what they're doing ^^).

Looking at the change, it makes sense. When I looked at late last night/early this morning, I couldn't work out why the StringIO was needed at all, but, couldn't work how to fix it. I shouldn't have been trying to code at that time (I was up monitoring a work change being done by someone else).

I've done a quick test here, and it seems to be OK. My tests used both the Embed metadata and send-to-device.