[Device Plugin] Kobo Touch Extended Driver

[cybmole]

so its not a "known issue" to you then ?

I have seen it with 3 out of 3 published books. meanwhile, someone else in another thread has selected a public domain book & sent 2 versions ( epub & kepup.epub) to their kobo reader device directly i.e. without calibre & without this plug in. They did not get this very small font effect. That outcome suggests that it is not just a "difference between renderers " thing. That test was done with a Kobo Glo thoguh,not the same device as my aura HD , if that's a factor

please see here https://www.mobileread.com/forums/sho...d.php?t=235018

I am unsure what test to try next: I do have a non standard font size key in my calibre preferences which is why I ask if the plug in looks there. ( I set that a while ago to change how small, large x-large values are changed in conversions but most books don't have those, so mostly the font size key is ignored i think ). Anyway the books I am testing with went through a calibre epub to epub conversion before they were ever sent to my Aura, as that is a standard workflow for me. Amongst other things it adds the no hyphenation property to book CSS for me.
The only other thing I do with books before sending to Kobo is to remove all explicit line-height, and font-family declarations from CSS so that all the on-device options are enabled. I have either no explicit font size for paragraph styles or I leave a simple 1em value in place if already present.

I guess the next obvious test is to fake up a one page test "book" with minimal CSS, e.g. via sigil, & send that both directly & via the plug-in ? to see how the font is then rendered.
- unless there's some way to bring one of the kepub.epub files back from the Aura onto my PC so that I can compare it's CSS with that of the original epub? I think they are buried inside the aura's database though ?

[cybmole]

PS I i noticed when speed reading the thread, that a lot of folks were saying they'd lost reading stats for slde loaded books. the stats are there for me. Is that 'cos Kobo relented & backed down in time for my firmware version (software version 3.1.1) or did you implement a workaround as was being discussed back in the day ?
for the kepubs that I have sent via your plug in I see a &% read an an estimate of number of hours to go, per book. but only on the kepubs , not on the epubs that were sent without using your plug in. is ttat feature at-risk if I allow a firmware upgrade to latest 3.2 ?

[cybmole]

one more issue, sorry,
I think I see another artifact- I kill all hypenation in epubs via CSS, I still see some hyphenation in kepub. I can get rid off it by moving the device justification slider to off, instead of leaving it on full. but I don not have to do that for epubs.
For epubs it is completely stopped by adding the line body {adobe-hyphenate: none;} to CSS, and the device slider is not relevant.

so you must be doing some reprocessing in this area also.

NB I checked the book source code, the occasional hyphenation that I see on screen in kepub is font size dependent & it not caused by any soft hyphens in the book text.

the device justification slider does fix it though, which is strange, it should not be happening at all unless the access renderer is not honouring the
body {adobe-hyphenate: none;} command.

I have not seen this ever when reading books in android kobo app on tablet ( which treats all side loaded books as kepubs)

[glos]

just to let you see, these are the in-book stats for a sideloaded kepubified ebook on a aura hd with 2.8.1 firmware (i want to keep them so i will not upgrade): different from what you see on the reading stats page.
as for the font size difference i was always told here it was due to the different reader epub and kepub use.
sorry idk why the pics are always rotated...

[jgoguen]

Originally Posted by cybmole

so its not a "known issue" to you then ?

I have seen it with 3 out of 3 published books. meanwhile, someone else in another thread has selected a public domain book & sent 2 versions ( epub & kepup.epub) to their kobo reader device directly i.e. without calibre & without this plug in. They did not get this very small font effect. That outcome suggests that it is not just a "difference between renderers " thing. That test was done with a Kobo Glo thoguh,not the same device as my aura HD , if that's a factor

please see here https://www.mobileread.com/forums/sho...d.php?t=235018

I am unsure what test to try next: I do have a non standard font size key in my calibre preferences which is why I ask if the plug in looks there. ( I set that a while ago to change how small, large x-large values are changed in conversions but most books don't have those, so mostly the font size key is ignored i think ). Anyway the books I am testing with went through a calibre epub to epub conversion before they were ever sent to my Aura, as that is a standard workflow for me. Amongst other things it adds the no hyphenation property to book CSS for me.
The only other thing I do with books before sending to Kobo is to remove all explicit line-height, and font-family declarations from CSS so that all the on-device options are enabled. I have either no explicit font size for paragraph styles or I leave a simple 1em value in place if already present.

I guess the next obvious test is to fake up a one page test "book" with minimal CSS, e.g. via sigil, & send that both directly & via the plug-in ? to see how the font is then rendered.
- unless there's some way to bring one of the kepub.epub files back from the Aura onto my PC so that I can compare it's CSS with that of the original epub? I think they are buried inside the aura's database though ?

The CSS changes you're doing with calibre may or may not be part of the problem. Try a normal ePub, one you've never converted or edited, and put it on the device manually without using calibre. if it looks fine, send it as a KePub through calibre, but do not do any of your normal workflow - just add the book to calibre and send the book to your device. See what the fonts look like then.

KePub books are stored just like normal ePub books. The specific location is determined by your save template in the driver settings.

[jgoguen]

Originally Posted by cybmole

PS I i noticed when speed reading the thread, that a lot of folks were saying they'd lost reading stats for slde loaded books. the stats are there for me. Is that 'cos Kobo relented & backed down in time for my firmware version (software version 3.1.1) or did you implement a workaround as was being discussed back in the day ?
for the kepubs that I have sent via your plug in I see a &% read an an estimate of number of hours to go, per book. but only on the kepubs , not on the epubs that were sent without using your plug in. is ttat feature at-risk if I allow a firmware upgrade to latest 3.2 ?

There's two types of stats. The ones we lost (and are mostly quite unhappy about losing!) are the detailed in-book stats including bar graphs representing the length of each chapter, as well as estimated times remaining to finish both the current chapter and the next chapter. The stats you're seeing were (obviously enough) not removed, and they have their own utility (such as letting me know if I could finish a book before my wife starts telling me I'm staying up too late ), but they're pretty basic and you don't get the same detail as before. I think the detailed stats are still available if you edit your 'Kobo Reader.conf' file and long-press on a book in the library view (davidfor/PeterT, is that right?).

If you upgrade to 3.2.0 you'll keep the basic stats you see now.

[jgoguen]

Originally Posted by cybmole

one more issue, sorry,
I think I see another artifact- I kill all hypenation in epubs via CSS, I still see some hyphenation in kepub. I can get rid off it by moving the device justification slider to off, instead of leaving it on full. but I don not have to do that for epubs.
For epubs it is completely stopped by adding the line body {adobe-hyphenate: none;} to CSS, and the device slider is not relevant.

so you must be doing some reprocessing in this area also.

NB I checked the book source code, the occasional hyphenation that I see on screen in kepub is font size dependent & it not caused by any soft hyphens in the book text.

the device justification slider does fix it though, which is strange, it should not be happening at all unless the access renderer is not honouring the
body {adobe-hyphenate: none;} command.

I have not seen this ever when reading books in android kobo app on tablet ( which treats all side loaded books as kepubs)

I only do hyphenation processing if you select that option in the driver settings. Otherwise I leave it at whatever the book's internal CSS rules are at the time it's sent to the device.

[davidfor]

Originally Posted by jgoguen

There's two types of stats. The ones we lost (and are mostly quite unhappy about losing!) are the detailed in-book stats including bar graphs representing the length of each chapter, as well as estimated times remaining to finish both the current chapter and the next chapter. The stats you're seeing were (obviously enough) not removed, and they have their own utility (such as letting me know if I could finish a book before my wife starts telling me I'm staying up too late ), but they're pretty basic and you don't get the same detail as before. I think the detailed stats are still available if you edit your 'Kobo Reader.conf' file and long-press on a book in the library view (davidfor/PeterT, is that right?).

If you upgrade to 3.2.0 you'll keep the basic stats you see now.

Yes, all that is right. The stats for sideloaded books show the details for the current book by pressing "Extras" and "Reading Stats" on the home screen. But, by adding "BookSpecificStats=true" into the "FeatureSettings" section of the config file, the menu for each book in the library list has "Reading stats" on it. This displays the stats for the selected book.

[cybmole]

Originally Posted by jgoguen

There's two types of stats. The ones we lost (and are mostly quite unhappy about losing!) are the detailed in-book stats including bar graphs representing the length of each chapter, as well as estimated times remaining to finish both the current chapter and the next chapter. The stats you're seeing were (obviously enough) not removed, and they have their own utility (such as letting me know if I could finish a book before my wife starts telling me I'm staying up too late ), but they're pretty basic and you don't get the same detail as before. I think the detailed stats are still available if you edit your 'Kobo Reader.conf' file and long-press on a book in the library view (davidfor/PeterT, is that right?).

If you upgrade to 3.2.0 you'll keep the basic stats you see now.

ok _ I was not aware of the detailed stats. ( the ones in the posted picture above) you are right I don't have those ( leastways I can't find any button that would bring them up, but as I've never had them I can't say that I miss them. So if a grab a book from the Kobo store, I should see those extra stats for that book? - I can test that with a freebie btu it's not a feature I am fussed about.

PS the justify issue that I posted about. I guess that is a fetaure of the Kobo renderer, and is controlled be the e-reader settings. I don't see it in the tablet app because it's not there! the tablet does not have that choice of J settings & it goes with the one I want, which is no hyphenation, so all is good there.

I will continue to puzzle over & test the small font issue.

I have not dared mess with the reader conf file yet. I believe you have to go there also to address the long paragraph bug, but also that you have to re-do that file whenever you allow a firmware change.

[cybmole]

Originally Posted by jgoguen

I only do hyphenation processing if you select that option in the driver settings. Otherwise I leave it at whatever the book's internal CSS rules are at the time it's sent to the device.

I have yet to find a driver settings screen ?

calibre preferences..plugins....customise plug-in just offers me a list of formats to tick and tickbpxes for metadata & subdirectories.

are there other settings somewhere else e.g. accessed only when the device is connected- seems not- if I connect & go to configure device I get same screen as before.

To confirm: in my plug in list I have 2 x greyed out kobo drivers, then one active driver - yours - version 2.2.14

[cybmole]

Originally Posted by jgoguen

The CSS changes you're doing with calibre may or may not be part of the problem. Try a normal ePub, one you've never converted or edited, and put it on the device manually without using calibre. if it looks fine, send it as a KePub through calibre, but do not do any of your normal workflow - just add the book to calibre and send the book to your device. See what the fonts look like then.

KePub books are stored just like normal ePub books. The specific location is determined by your save template in the driver settings.

OK I am using the test book used in the other thread, from this site - the widow Lerouge. I put that into calibre & send it with your driver.
I now also rename the downloaded copy in windows & put it on the device manually as "the widow book - test_case.epub" placing it in device root directory - now to disconnect...

oops - looks like the epub has overwritten the kepub despite my changing file name - so (memorise font size) delete epub, try again... shows up as unread kepub.. font is much smaller than the epub was, a few minutes ago.

So can you try to duplicate that please. the link to the book is in an earlier post.

we now have a downloaded PD book, sent to aura HD, firmware 3.1.1. with your driver & also sent manually without calibre, & I see big font size differences i.e. the kepub is much smaller
here is the book link:
https://www.mobileread.com/forums/showthread.php?t=44226

[jgoguen]

I'll look at it when I get a chance, sure. It may be a day or two, it's harder to reproduce bugs like that with a baby in one arm

That window you get when you customise the KoboTouchExtended plugin is the driver settings window. One of the check boxes there is 'Hyphenate Files'; if it's selected I add hyphenation CSS (but I do not modify what's already in the book's CSS), if it's not selected I don't touch hyphenation at all.

[cybmole]

you are right of course.

I completely missed that there are two window scroll bars - on for the file types, then another outside one to get to other options. so I was not seeing them because I had not scrolled the whole window.

But there is no obvious suspect in those lower options for affecting font size anyway.

I do have one new thought:
It could be that I should have done my tests using document default as the font rather than geogria, because georgia font has another screen of advanced settings with yet another font size slider. maybe one of other of the 2 renderers reads that 2nd level differently, or ignores it ?

[jgoguen]

I don't know how the Adobe RMSDK renderer for ePub files handles the font settings, but the font settings work fine at both normal and advanced levels for the ACCESS KePub renderer. Try again with something other than Document Default though, there are issues with Document Default a lot of times.

[cybmole]

Originally Posted by jgoguen

I don't know how the Adobe RMSDK renderer for ePub files handles the font settings, but the font settings work fine at both normal and advanced levels for the ACCESS KePub renderer. Try again with something other than Document Default though, there are issues with Document Default a lot of times.

Actually, my previous test was NOT with document default - they were with that named book & with my device default font set to georgia

I was thinking of using document default for new tests - to eliminate another variable - but maybe not, given your last post.

It may be that nothing is actually bugged, you need to have a mix of side loaded epub & kepub on the device to notice the issue & I guess many folks have just one or the other ?

there probably is some relevant discussion buried in the 1000s of pages on the Kobo forum, but finding it....

the site search engine is happy to suggest a few 100+ page threads but is crap at indicating a specific post