[Device Plugin] Kobo Touch Extended Driver

[NiLuJe]

@jgoguen: No problem .

I'll be waiting for more people to test this though, because after a bit more testing, I appear to have managed to break stuff in certain circumstances (cf. latest edit of #1137) ^^.

That said, I can launch the PR right now if you prefer that as a means of code review?

(In the mean time, pushed on GH).

[GeoffR]

I think the book's stylesheet will override the patched device stylesheet, so If the plugin adds padding to div#book-inner in the book's stylesheet then idealy it should choose either left/right padding or top/bottom padding depending on whether the writing direction is horizontal or vertical, or if that is not possible then just add padding to all four sides.

I also wonder if we should add the padding to div#book-columns instead of div#book-inner, so that people can still use the alternative firmware patch that adds padding via the body>* selector? (Some might want to do this if they have a mix of kepubs made with the old and new plugins.)

[davidfor]

I don't think the css should hard-codes the plugin. Reading it from a configurable file is the most flexible. Or leave it completely alone. Once the divs are in the book, then the patch should work. Or use the "Modify CSS" and the kobo_extra.css file to add them during the send should work.

If it is hard-coded, it should be identical to what Kobo is using. Adding the other two rules forces them on people who might not want them. And is that padding correct for all devices? Or just the H2O and HD?

[GeoffR]

Originally Posted by davidfor

Or leave it completely alone. Once the divs are in the book, then the patch should work. Or use the "Modify CSS" and the kobo_extra.css file to add them during the send should work.

That makes sense.

If it is hard-coded, it should be identical to what Kobo is using. Adding the other two rules forces them on people who might not want them. And is that padding correct for all devices? Or just the H2O and HD?

Kobo doesn't use any padding. The firmware patch adds 0.2em by default, so it is proportional to the font size set by the slider, and should be independant of screen resolution.

0.2em is just what seems to work from the testing that has been done so far, it seems to be enough to prevent any cutoff of an italic f at font size 1em or a normal f at font size 2em, which should be good enough for most books, but there will probably be some situations where the cutoff still happens, such as a 2em italic f which might occur in a right-justified heading.

[NiLuJe]

@davidfor/@GeoffR: Speaking of, I actually appear to have vanilla kepubs *without* those specific divs (and style-hacks, except for the .koboSpan thingy) [at least according to the liberated Kobo Desktop version of the file. The one on my H2O looks the same, but with it being encrypted, who knows]. Yet the book-inner/book-columns stuff is still mentioned in the js :?.

One common trait to those books is that they *already* wrap the full body in a single div (although not book-inner and/or book-columns). And I could swear those don't suffer from the cutoff bug.

Since I basically just threw myself in the deep-end of Kobo arcane stuff here, I'd be glad for some more feedback on that point .

[jgoguen]

My slightly-educated opinion on the matter is to please try to emulate the current "real" KePubs as closely as possible Ignore what's in the JS and CSS files and build the KePub structure based on observations of a few Kobo-supplied books. I didn't necessary do that at first and it resulted in a lot of avoidable problems.

EDIT: As for JS and CSS files, try to use the mechanism I'm using for "reference.kepub.epub" or (probably better) work with the existing code for sending a device-based CSS file. You could easily add code to do the same for JS files.

[NiLuJe]

@jgoguen: The issue with this specific bit of CSS (the kobo stylehacks) is that (when present), it's inlined in each (x)html file, and not evacuated to an external CSS, so we can't (easily) use the same mechanism as for the JS ;/.

----

To illustrate my previous message, I forgot to mention that those books of course use 0 padding & margin, and yet, no cut-off... :?

The code basically looks like

<body>
    <div class="galley-rw">
        ...
    </div>
</body>

.galley-rw { padding: 0; font-size: 1em; font-weight: normal; color: rgb(0, 0, 0); orphans: 1; widows: 1; letter-spacing: 0; word-spacing: 0; font-family: serif; margin: 0; line-height: 1.2em; text-align: justify; }

FWIW, that's the book.

[PeterT]

I think you need to look at the "age" of the kepub; I think there have been changes over the years in the conversions done, and I'm not sure they go back and reconvert all material.

[NiLuJe]

@PeterT: Valid point. That's a fairly recent book (September 2014), as are the few others I have that look like that.

[jgoguen]

Yay inline CSS<!>

If you declare an external stylesheet and make sure it's the second-to-last stylesheet defined (since the user stylesheet should override this one) then you don't need to inline the CSS. There's an order of precedence for styles: external sheets (in document order), inline styles in the <head> in order, and styles on each tag.

[NiLuJe]

@jgoguen: To be clear, because I'm starting to get confused myself ;D:

It's inlined in vanilla kepubs. The patched version of the plugin puts it in an external stylesheet, defined hopefully last or next-to-last. Good point about the kobo_extra one though, I'll see where that one falls .

[jgoguen]

@NiLuJe: To keep things easier to manage, what I'd recommend is that you start from the master branch as it was when you forked, then create a branch for each distinct change (git checkout -b branch-name), make only your distinct changes for the one branch, push it, and make a pull request for each branch. Then go back to master and make a new branch and start on the next distinct feature.

[GeoffR]

Originally Posted by NiLuJe

@davidfor/@GeoffR: Speaking of, I actually appear to have vanilla kepubs *without* those specific divs (and style-hacks, except for the .koboSpan thingy) [at least according to the liberated Kobo Desktop version of the file. The one on my H2O looks the same, but with it being encrypted, who knows]. Yet the book-inner/book-columns stuff is still mentioned in the js :?.

One common trait to those books is that they *already* wrap the full body in a single div (although not book-inner and/or book-columns). And I could swear those don't suffer from the cutoff bug.

Since I basically just threw myself in the deep-end of Kobo arcane stuff here, I'd be glad for some more feedback on that point .

All I can think is to check that it really is a kepub, some books synced from the Kobo server are actually epubs, and get opened with the epub reader, although I've only ever seen that with free books. The margins in your screenshot make it look like this is being viewed in the epub reader, the kepub reader has larger margns, unless you are using the `Custom kepub default margins` patch?

Also the screenshot doesn't show any f characters at the right of the screen, f is the only character I usually see cut off. Can you check to see if an f gets cut off at the right?

[NiLuJe]

@GeoffR: Definitely a kepub, and not the only one like that (mostly from Hachette, AFAICT) (flagged as KOBO EPUB in the UI, no adobehost process run, bearable pageturn speeds, and kepub font rendering, so I'm fairly sure of that ).

But yes, I am indeed using the nerfed kepub margins patch (default values) .

Good point on the f's though, I'll check .

[GeoffR]

Originally Posted by NiLuJe

FWIW, that's the book.

Hmm, I see that book doesn't have an epub2 download option, so I think the publisher must have supplied an epub3, and in that case it hasn't gone through Kobo's epub2 to kepub conversion process where the book-inner and book-columns divs get added.