[Device Plugin] Kobo Touch Extended Driver - Page 200

jgoguen · 07-08-2024, 11:20 PM

This looks different from the example in the book I looked at. This seems to be making paragraph lines (or a fake list) indented, which I may not like visually but off the top of my head I expect what you show in the image could be done without god-awful markup and questionable CSS choices. I'd prefer to see it done with <ol> or <ul> and styling the <li>, but there are other clean ways to do it. Just my own personal preference not liking how this looks rather than a final product that makes me question how much the publisher actually knows about HTML or CSS.

The book example I was commenting on is a case where a <dl> is both a clean and natural choice. The <dt> in that case would be the name of the speaker and the <dd> would be the text. Style it to float the <dt> to the left at some low percentage width and <dd> to the right at remaining width and you've got the same effect with much cleaner markup and CSS.

Quoth · 07-09-2024, 07:57 AM

using <p> with suitable classes is more reliable and can exactly duplicate ol ul li etc, which are needed for server side auto-generated content from a database, or a convenience. They are not needed at all in ebooks.

No need for dd or dt and float is best avoided in ebooks.

JSWolf · 07-09-2024, 05:21 PM

Quote:

Originally Posted by Quoth

using <p> with suitable classes is more reliable and can exactly duplicate ol ul li etc, which are needed for server side auto-generated content from a database, or a convenience. They are not needed at all in ebooks.

No need for dd or dt and float is best avoided in ebooks.

I prefer a flat <p> for most paragraphs.

mgrimace · 07-09-2024, 05:55 PM

Quote:

Originally Posted by jgoguen

I suspect what's happening here is a matter of the book cover versus the metadata cover. In calibre's file system, alongside the book you'll see "cover.jpg". This is what gets added to the book file unless you specify different options in conversion. If you unpack the KePub and inspect the converted book cover and cover.jpg, I bet they're different.

Beyond here I'm a little more fuzzy on details. As I understand it, metadata sent over to Kobo by calibre-web, as a consequence of how Kobo syncs, is the metadata shown in the UI, not what's in the book itself. The cover is included in "metadata" and is fetched by Kobo separately from the book, and you get whatever is cover.jpg showing as the book cover on the device. If you open your book and go back to the cover page, it's probably the image you're expecting to see.

So, my best educated guess would be to change the cover itself in calibre to be the dimensions you want rather than do it in book conversion options. How exactly, I'm not sure, I don't have a calibre install accessible right now and I've never needed to do it.

Thanks so much for that thoughtful explanation, it makes sense, I think. I'm murky when it gets to the overlap of covers and metadata as well.

I'll try out changing the 'physical' dimensions of cover.jpg - I was kind of hoping to avoid it, and just 'spanning' them if possible, but proper dimensions for my reader would be a tidier solution to just have consistent covers overall. I know there's plugins that can do this as well.

Thanks so much!

jgoguen · Yesterday, 08:16 PM

v3.6.8 should be showing up in calibre soon. This release fixes handling HTML file names from content.opf with URL-encoded characters (like part%28001%29.xhtml -> part(001).xhtml).

SuperBee · Yesterday, 09:51 PM

pretty sure 3.6.8 has a bug surfaced from a change several months ago that never got pushed. It's not able to convert to kpubs.

I'm pretty sure common.py line 141, the {v} should be {cover_id}. Made the change locally and it works now.

JDesat · Yesterday, 11:11 PM

Quote:

Originally Posted by SuperBee

pretty sure 3.6.8 has a bug surfaced from a change several months ago that never got pushed. It's not able to convert to kpubs.

I'm pretty sure common.py line 141, the {v} should be {cover_id}. Made the change locally and it works now.

Since I don't know how to "make the change locally", is there a way to roll back the plugin to the last version? I can't upload anything to my Kobo now.

EDIT: Nevermind, I downloaded the zip and opened common.py in notepad and made the change then installed that manually. Thanks for the info, SuperBee!

0x6f677548 · Today, 04:10 AM

Quote:

Originally Posted by SuperBee

pretty sure 3.6.8 has a bug surfaced from a change several months ago that never got pushed. It's not able to convert to kpubs.

I'm pretty sure common.py line 141, the {v} should be {cover_id}. Made the change locally and it works now.

I second this. thanks!

ownedbycats · Today, 05:01 AM

Gah, I wish I'd seen this thread before updating. Thanks to SuperBee.

kangaroo2 · Today, 06:29 AM

someone opened a PR with the fix in the github repo https://github.com/jgoguen/calibre-kobo-driver/pull/171

Hopefully it gets merged soon

JSWolf · Today, 06:46 AM

Quote:

Originally Posted by SuperBee

pretty sure 3.6.8 has a bug surfaced from a change several months ago that never got pushed. It's not able to convert to kpubs.

I'm pretty sure common.py line 141, the {v} should be {cover_id}. Made the change locally and it works now.

I've made this change and and updated the version to 3.6.9. I've attached it here to be tested.

If it works, someone with access can attach it to the first post and I can delete this attachment.

svenlind · Today, 07:03 AM

I tried the edit as suggested by SuperBee and it worked. Also thanks to JDesat for explaining how to do it.
I did not catch the edit by JSWolf. If in doubt use his version.
Many thanks to all of you.

Yesterday, 09:51 PM	#2991
SuperBee Junior Member Posts: 1 Karma: 5316 Join Date: Aug 2024 Device: kobo libra 2	pretty sure 3.6.8 has a bug surfaced from a change several months ago that never got pushed. It's not able to convert to kpubs. I'm pretty sure common.py line 141, the {v} should be {cover_id}. Made the change locally and it works now. Last edited by SuperBee; Yesterday at 09:53 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Kobo Device Driver Update	davidfor	Devices	284	05-24-2019 05:24 PM
[Device Plugin] Kindle 2, 3, 4, Touch Device Interface MBP Update Mod	cryzed	Plugins	7	10-28-2012 04:58 PM
[Device Interface Plugin] Update for Nook Color Driver	jmricker	Plugins	0	10-22-2011 10:11 AM
Touch Kobo Touch Extended 2 Year Warranty - Is it worth the $34.99?	EverC	Kobo Reader	11	08-31-2011 11:47 PM
Touch Kobo Touch Extended Warranty Program	SensualPoet	Kobo Reader	1	07-17-2011 04:08 AM

07-08-2024, 11:20 PM	#2986
jgoguen Generally Awesome Person Posts: 1,071 Karma: 2178845 Join Date: Jan 2013 Location: /dev/kmem Device: Kobo Clara HD, Kindle Oasis	This looks different from the example in the book I looked at. This seems to be making paragraph lines (or a fake list) indented, which I may not like visually but off the top of my head I expect what you show in the image could be done without god-awful markup and questionable CSS choices. I'd prefer to see it done with <ol> or <ul> and styling the <li>, but there are other clean ways to do it. Just my own personal preference not liking how this looks rather than a final product that makes me question how much the publisher actually knows about HTML or CSS. The book example I was commenting on is a case where a <dl> is both a clean and natural choice. The <dt> in that case would be the name of the speaker and the <dd> would be the text. Style it to float the <dt> to the left at some low percentage width and <dd> to the right at remaining width and you've got the same effect with much cleaner markup and CSS.

07-09-2024, 07:57 AM	#2987
Quoth the rook, bossing Never. Posts: 12,050 Karma: 88064427 Join Date: Jun 2017 Location: Ireland Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper11	using <p> with suitable classes is more reliable and can exactly duplicate ol ul li etc, which are needed for server side auto-generated content from a database, or a convenience. They are not needed at all in ebooks. No need for dd or dt and float is best avoided in ebooks.

Yesterday, 08:16 PM	#2990
jgoguen Generally Awesome Person Posts: 1,071 Karma: 2178845 Join Date: Jan 2013 Location: /dev/kmem Device: Kobo Clara HD, Kindle Oasis	v3.6.8 should be showing up in calibre soon. This release fixes handling HTML file names from content.opf with URL-encoded characters (like part%28001%29.xhtml -> part(001).xhtml).

Today, 05:01 AM	#2994
ownedbycats Custom User Title Posts: 9,058 Karma: 62040591 Join Date: Oct 2018 Location: Canada Device: Kobo Libra H2O, formerly Aura HD	Gah, I wish I'd seen this thread before updating. Thanks to SuperBee.

Today, 06:29 AM	#2995
kangaroo2 Junior Member Posts: 1 Karma: 10 Join Date: Aug 2024 Device: Kobo clara BW	someone opened a PR with the fix in the github repo https://github.com/jgoguen/calibre-kobo-driver/pull/171 Hopefully it gets merged soon

Today, 07:03 AM	#2997
svenlind Fanatic Posts: 511 Karma: 10491195 Join Date: Apr 2010 Location: Denmark Device: Oasis 3, Kobo Sage and Libra 2,Ipad mini 5	I tried the edit as suggested by SuperBee and it worked. Also thanks to JDesat for explaining how to do it. I did not catch the edit by JSWolf. If in doubt use his version. Many thanks to all of you.