Clara Mediocre user experience with new Clara HD

Originally Posted by JSWolf

@maximus83, is this in ePub or kepub format? There are two different renderers on a Kobo and one could be faster then the other at links for rather large eBooks.

The original download of the book using ADE was a .epub file.

Originally Posted by GeoffR

The problem is not large books in general, but large html files (or other objects) within the book.

The device only needs to have one or two html files loaded into memory at once, the one containing the page you are reading, and perhaps the one containing the page a link leads to if you are activating the link.

If the book is broken up into lots of small html files then limited RAM is no problem no matter how long the book. But if the book consists of a small number of very large html files then there will be problems. (Some devices will simply crash, others will be slower.)

If the publisher is competent then they will break the large book up into many small html files, but if not then the only real solution is to edit the book and fix the publisher''s mistakes yourself.

(If the book has been converted from another format then it might not be the publisher's mistake but the converter's mistake.)

Geoff, that all makes sense. Maybe as an experiment, I should convert the book simply to split apart large files into smaller ones of 260K or less? I noticed just now clicking into edit mode on the book, there are a boatload of contained XHTML files that are of larger sizes: many many files are 400K to 800K, I didn't spot any over 1MB.

[davidfor]

Originally Posted by christopher22

If you're looking for a large book, here is a rather VERY large book.
https://www.kobo.com/us/en/ebook/the...-of-the-fallen
It's some 10,083 pages long!

Actually the number of pages changes. In the link I provided, it actually states 11,927 pages, the description on amazon says 10,083 pages. And in a couple of epub's from the library one is 8,344 pages and the other is 8,244 pages. I think it's just the font sizes selected for the books that are causing the differences and not (hopefully) missing pages.
Regardless, that's one massive book.

It won't be the font size differences. It will be the algorithm used to calculate the pages. The ePub versions from the library will use the Adobe method. The Kobo site probably uses the word count. And I bet that Amazon is using a word count algorithm as well. And for the word count based algorithms, it then becomes about how to count the words. And that is a subject that makes me

[GeoffR]

Originally Posted by maximus83

Maybe as an experiment, I should convert the book simply to split apart large files into smaller ones of 260K or less? I noticed just now clicking into edit mode on the book, there are a boatload of contained XHTML files that are of larger sizes: many many files are 400K to 800K, I didn't spot any over 1MB.

800K is far too big and will certainly result in problems. Such a book wouldn't even be able to be opened on many older devices.

Doing a Calibre conversion can help with some books, but it depends on whether Calibre is able to pick up the appropriate locations to break the files. A conversion can also introduce other problems such as the line-spacing or font-face becoming locked.

If the book has a conventional structure with chapter headings like "Chapter One", "Chapter Two" etc. or if the publisher has used appropriate html heading tags <h1>, <h2> etc. then Calibre will be able to use these as a guide to where to insert the file breaks. But if not then the breaks will occur at arbitrary locations, and the results will not be ideal, although it might still be an improvement on the original.

To get best results for books that don't have a conventional chapter structure you will probably have to locate the break points by hand, which can be a lot of work for a large book.

(Edit: Just a warning that if splitting the html files you should delete the old book from the device before loading the converted book with Calibre, so the the device notices the file structure of the book has changed. If you just "send to device" while the old book is still on the device then there will be problems.)

[DNSB]

Originally Posted by FrustratedReader

Yes, Calibre has a setting for internal file size, default about 260K.
That said, quite obviously Kobo test their sw better on kepubs than epubs, but it's also obviously buggy.

There were pretty decent reasons as to why the original epub 2.0 spec set the maximum file size to 300KB. While improvements have reduced the effects of overly large file sizes due to the limited RAM in most ereaders, large chunks of text still have issues. I have noticed this with a couple of omnibus volumes where each of the original items was stored as a single html file. One nasty noted is that when a link to a footnote in one large chunk pointed into another large chunk, the ereader appears to be paginating every page between the link and it's destination. So if I was in the first book and went to a footnote, the ereader was forced to paginate hundreds if not thousands of pages to get to the footnote.

Please note that in my testing, I found I could trigger this behaviour on my laptop which is a pretty decent machine (i7, 32GB RAM, 2TB NvMe SSD). Simply breaking up the books so each chapter was it's own file made that hesitation disappear.

Also please note that Kobo does not write either of the renderers used in it's eInk ereaders.

For epub2 with Adobe DRM support, they use RMSDK which is an Adobe product though it seems to be commercialized through 3rd parties such as Datalogics.

For epub3 with support for Kobo's proprietary DRM, they originally used the ACCESS NetFront BookReader EPUB Edition. ACCESS donated a good chunk of their WebKit based code to the Readium project. While I haven't run into mentions of Readium in the Kobo firmware, Tolino's firmware does make mention of Readium in a couple of modules though oddly, there seems to be no support for epub3.

From Datalogics' website, it appears that RMSDK 11 also uses the Readium codebase (might that be the reason that RMSDK gets excellent ratings for rendering epub3s? ). However if Kobo was planning on going to a single renderer, they would run into a licensing issue where you are prohibited from using non-Adobe DRM with the RMSDK renderers.

[Quoth]

It's quite normal that eReaders and eReader apps use off the shelf sw for the actual reader. DRM on ePub is generally Adobe. I'm for Copyright, but DRM is a nasty immoral lazy way to enforce it. Hence an Adobe reader.
However the actual reader software is used in an app or ereader HW specific system, which does the GUI, selection of text, search, notes, bookmarks, library management, navigation, touch keyboard & text entry etc.
All such is pretty poor on kindle and worse on kobo. Kobo certainly has more bugs too.
Bugs with in the actual reader code obviously can only be fixed by Kobo's supplier. Comparing other eReaders that have a Adobe DRM, I conclude that those bugs are not such an issue as the Kobo specific firmware. The Sony, Nook and Binatone HW I have all have Adobe DRM support. The Binatone uses the Adobe reader if the non-DRM epub is in the Digital Editions folder and then renders publisher fonts, otherwise something else that ignores fonts in the ePub and also formats differently! So if the eBook is DRM free and publishers fonts are horrid, it works better outside the Adobe folder.

What decides which reader is used on the Kobo? Obviously the Adobe one for Adobe DRM.

[PeterT]

Originally Posted by FrustratedReader

What decides which reader is used on the Kobo? Obviously the Adobe one for Adobe DRM.

The type of the file. ePubs (all of which are sideloaded) use ADE / RMSDK.

Kobo format ePubs (bought from Kobo and synced by Kobo Desktop or WiFi, and sideloaded content with the .epub.kepub extension) use Netfront ACCESS

[Asiorent]

I think we should not have unrealistic expectations from an e-reader, it is not a tablet!

I have Kobo Clara HD and true, the swiping left edge of screen very often instead of changing brightness is selecting the text, meaning very often you don't get it right and have to do it the regular way (through middle tap). Realistically I don't care, I don't change the brightness so often and for me its not a deal braker.

Opening MASSIVE e-book 13 000 pages (more than 120 MB) needs 14-15 sec (just measured) but hey 13 000 pages???? Normal books are opened either instantly or with delay of several seconds, completely acceptable.

Who wants faster performance should get one of the bigger Android e-readers who are actually hybrid tablet-e-readers.

I'm very happy with my Clara .

[Quoth]

I got a big compendium of 18th C novels. I used Calibre to split it into separate eBooks. Much better for reading & research. I'd do that with Shakespeare complete works too, except I have the few Shakespeare plays I want as separate eBooks from Gutenberg as a well as some on paper.
The only bible I have that's slow is an old Jewish one in English that's a PDF. The others I have seem well designed for eReader use, though I've not tried NIV yet. Though for research I often use online ones that allow several translations at once. Like exactly what context and how often is Lilith, Nephilim and horsemen of the Apocalypse etc? All useful info for either reading some fantasy works or writing them. George Macdonald's Lilith is rather vampirish. His Lilith isn't one of the easier 19th reads, but interesting. I have it on paper and from Gutenberg.

Originally Posted by GeoffR

800K is far too big and will certainly result in problems. Such a book wouldn't even be able to be opened on many older devices.

Here's an update: success! Converted the Shakespeare in Calibre, the only setting I changed from the default was to set output format to epub 3. The conversion took a LOOOOONG time. This book has thousands and thousands of internal links to footnotes, as well as many chapter, scene, and other divisions. After conversion, the .epub file went from 36MB to 11MB, and the internal XHTML files were split into many smaller ones. I didn't see any file larger than 100K after the split, and most were in the 10-50K range. After sideloading to Clara, the book was immediately more snappy and responsive on page turns, especially when clicking the links to the footnotes (which usually have to jump to a notes page that's a long way away in the book, then return back to your reading position when done). Calibre handled this large conversion really well, I have yet to see any issues in the rendered output even after it did all that file splitting and link updating.

Originally Posted by DNSB

There were pretty decent reasons as to why the original epub 2.0 spec set the maximum file size to 300KB. [...]
Simply breaking up the books so each chapter was it's own file made that hesitation disappear.

For sure, that's what made the difference in this case.

[fendesa]

Originally Posted by maximus83

Here's an update: success! Converted the Shakespeare in Calibre, the only setting I changed from the default was to set output format to epub 3. The conversion took a LOOOOONG time. This book has thousands and thousands of internal links to footnotes, as well as many chapter, scene, and other divisions. After conversion, the .epub file went from 36MB to 11MB, and the internal XHTML files were split into many smaller ones. I didn't see any file larger than 100K after the split, and most were in the 10-50K range. After sideloading to Clara, the book was immediately more snappy and responsive on page turns, especially when clicking the links to the footnotes (which usually have to jump to a notes page that's a long way away in the book, then return back to your reading position when done). Calibre handled this large conversion really well, I have yet to see any issues in the rendered output even after it did all that file splitting and link updating.



For sure, that's what made the difference in this case.

wow interesting, the last time I converted from epub 2 to epub 3, the weight of the file was much larger. I felt like trying. Thank you for the trick.

Inviato dal mio WAS-LX1A utilizzando Tapatalk

Originally Posted by fendesa

wow interesting, the last time I converted from epub 2 to epub 3, the weight of the file was much larger. I felt like trying. Thank you for the trick.

Inviato dal mio WAS-LX1A utilizzando Tapatalk

In this case, I don't know if changing the output to Epub 3 did anything particular. I think it was simply the step of converting and splitting the many large internal files into smaller ones that made the real difference.

In fact, after this earlier post, I ran the conversion again, this time using Epub 2 as the output format. The file size dropped another 1MB (from ~11 to ~10MB), and the TOC was a little cleaner. So I stuck with the Epub 2 as the final version.

[GeoffR]

If the size of the book drops a lot when converted it could be either there were a lot of redundant styles or other rubbish that got cleaned out (a good thing), or it could be that the images in the book got downsized (usually a bad thing.)

To avoid images being downsized, make sure you have the output profile set to "Tablet" or "Generic e-ink HD" and not to "Kobo Reader". (The "Kobo Reader" profile is only for the ancient original Kobo devices that had extremely low-resolution screens.)

Originally Posted by GeoffR

To avoid images being downsized, make sure you have the output profile set to "Tablet" or "Generic e-ink HD" and not to "Kobo Reader". (The "Kobo Reader" profile is only for the ancient original Kobo devices that had extremely low-resolution screens.)

That is another interesting tip--hadn't heard that about avoiding the Kobo output profile. I'll go rerun a conversion or two and see how it differs.

Besides the issue of images downsizing, is there any other reason to choose these other profiles over the Kobo one? Most of my conversions have no images, so if that's the only issue, I won't bother.

[davidfor]

Originally Posted by maximus83

That is another interesting tip--hadn't heard that about avoiding the Kobo output profile. I'll go rerun a conversion or two and see how it differs.

Besides the issue of images downsizing, is there any other reason to choose these other profiles over the Kobo one? Most of my conversions have no images, so if that's the only issue, I won't bother.

The profiles are only about the image size. They set the maximum image size. Any images larger than that will be downsized. Smaller images won't be touched.