Firmware 4.34.20097

[jackie_w]

Originally Posted by Aleron Ives

If the EPUB page numbers are in fact not based on a paper book, then I guess they are based on some arbitary metric of how many words "should" fit on a single page.

Although publishers can create a page-map for their epubs, in many cases it's left to the epub renderer (when based on the Adobe engine ADE) to provide a 'fake estimate' pagecount. Unfortunately it's not based on anything so logical as wordcount, it uses an algorithm based on the compressed filesize of the HTML files in the epub.

It does have the benefit of being consistent across devices/apps but as a realistic estimate of how long to read the book I've always found it pretty useless. Any epub with bloated HTML markup (and there are many) can look like a long book. I clean up all my epubs before I read them (sad, but true) and it's not unusual for the book's ADE pagecount to "lose" 50-60 pages after the excess markup was simplified. I think the biggest reduction I ever saw was 100+ pages.

[Sirtel]

Originally Posted by MGlitch

Adobe, which is probably what those librariy books were using, is worse than words per page. It’s bytes. And the developer of it, or one of them anyway, has said it was an arbitrary number of bytes that they basically pulled out of thin air.

Yeah, Adobe page numbers are a mess. That's why I prefer either Calibre-generated numbers or the kepub 1 screen=1 page numbers.

Of course, I don't care about chapter lengths at all and have disabled all headers and footers on my Kobos. The progress bar is enough for me, plus the overall page count generated in Calibre.

[Aleron Ives]

Originally Posted by jackie_w

I clean up all my epubs before I read them (sad, but true) and it's not unusual for the book's ADE pagecount to "lose" 50-60 pages after the excess markup was simplified. I think the biggest reduction I ever saw was 100+ pages.

What's involved in this cleaning process? It sounds like a pretty arduous process to me, considering just how much CSS alone I've seen in the few e-books I've checked so far.

[Sirtel]

Originally Posted by Aleron Ives

What's involved in this cleaning process? It sounds like a pretty arduous process to me, considering just how much CSS alone I've seen in the few e-books I've checked so far.

Calibre has an option to remove unused css rules and merge identical rules. Pretty often this removes hundreds of css rules left there hanging by the publisher. This makes the css editing hugely easier.

[Blas]

Is there anyone here having issues with this update when using sdcard?

Issue I am facing

Basically it will update fine either manually with downloaded file from PC or through the wifi.

The problem is when it boots up, it will just boot up with none of my reading stats available and it will not show my saved books in the sdcard. If I try to connect to my pc by usb(with the sdcard in) it will give the prompt to connect to the pc and show the screen that it is connected to the computer(as it normally does), after that it will freeze, the computer will never recognize that the kobo is connected therefore I can't navigate through its folders.
After a while the kobo will restart itself, with the same "blank" home screen where only the books that are loaded onto the onboard storage will be shown.

If I do the same procedure, but with the sdcard out, the computer will recognize the Kobo, I can navigate through its folders and even see that my database is there(which has ok pass on calibre) but still for some reason it will load the "blank" home page with reset books read, hours read and etc.

If I roll back to the 4.33.19759 it will work fine, computer will properly recognize my Kobo with the sdcard in and all my content will load in the home screen.

Notes:
> the updates were without any patches set
> tested different working usb cables
> database has ok pass in calibre

Kobo Model: Kobo Aura H20(kobo5)
SD Card: SanDisk 32GB Class 10
PC OS: Windows 11 Pro

[ZodWallop]

Originally Posted by JSWolf

It's because StandardEbooks code is bad. They use overly complicated CSS code and a lot of their eBooks don't work well with RMSDK because of what RSMSDK perceives are errors.

I've read StandardEbooks on both my Nooks and Kobo and have never had am issue, so I do have the benefit of first hand experience compared to your hearsay and guesses.

I haven't downloaded a kepub from Standard as I download the ePub and use TouchExtended to convert. But the ePubs never gave me any problems.

Advanced ePub is worthless as there's no need for it. Have you ever seen a public domain book that needs An advanced format that uses the latest technology not yet fully supported by most ereaders? Of course not, because there are none.

It's just ePub 3. Why the rant?

[DNSB]

Originally Posted by Aleron Ives

What's involved in this cleaning process? It sounds like a pretty arduous process to me, considering just how much CSS alone I've seen in the few e-books I've checked so far.

My choice is to use Sigil to do much of the cleaning. The builtin Delete Unused Stylesheet Selectors (remove unused stylesheet entries) and the plugin cssUndefined Classes (remove undefined classes in the html files) do a very decent first pass. For those epubs where the author went for inline styles, the RemoveInlineStyles creates a stylesheet and moves the inline styles to the stylesheet. At times, after running those in Sigil, I will then use calibre's editor to merge similar styles—do you really need 6 paragraph styles with the only difference being the line height being set from 1.0 to 1.35?

[Aleron Ives]

That sounds like the cleaning process could easily become extremely time consuming if your goal is to reverse all the stupid formatting decisions made by the publisher...

Out of curiosity, can you be naughty and delete the CSS entirely and use HTML4 font tags, instead?

[Sirtel]

Originally Posted by Aleron Ives

That sounds like the cleaning process could easily become extremely time consuming if your goal is to reverse all the stupid formatting decisions made by the publisher...

I never go that far. I only remove/replace the things I know for sure would bother me - hard-coded body font family and font size (other than 1em), body margins, line-height, text indents other than 1em, spaces between ordinary paragraphs, ragged right, widows/orphans other than 1. And I strip out unused rules and styles, which is a one-click job in the Calibre editor. The rest I leave alone. I never even error check, unless one of my Kobos starts protesting (which is rare).

[hobnail]

Originally Posted by Aleron Ives

That sounds like the cleaning process could easily become extremely time consuming if your goal is to reverse all the stupid formatting decisions made by the publisher...

Out of curiosity, can you be naughty and delete the CSS entirely and use HTML4 font tags, instead?

That's essentially what I do. My goal is to open a cleaned book and have the font size, line height, and margins always be the same; I set them with the sliders in the Kobo's reading settings. Before I nuke the book's original css I go through and find all of the classes that set bold, italic, and italic bold and add them to my css. My search string for that is

bold|italic|font-weight: [56789]

The vast majority of these are books that have been converted to EPUB from the Kindle formats and I have calibre "normalize" a lot of stuff in the process. I suspect that calibre fixes weird stuff like inline styles. Doing this I rarely have to do anything to the html files, although occasionally there are books that use div tags instead of p tags, and recently there was one that had a space entity wrapped in p tags between every paragraph (I guess ensuring that there was a blank line between paragraphs).

This is the css that I replace the book's with.

body {
  font-size: 100%;
  border: 0;
  margin: 0;
  padding: 0;
  width: auto;
}

body * {
  line-height: inherit;
}

p {
  font-size: 100%;
  margin: 0;
  padding: 0;
  border: 0;
  text-indent: 2em;
}

h1,h2,h3,h4 {
  text-align: center;
}

.bold {
  font-weight: bold;
}

.italic {
  font-style: italic;
}

.bold_italic {
  font-weight: bold;
  font-style: italic;
}

It's not pretty since all text is the same size, in particular the chapter headings/titles since most books use p tags instead of h tags, and the chapter headings are often right above the first paragraph with no space. But it's a small price to pay for how quick it is to clean a book. I probably download at least 7 free books a week by using ereaderiq.com so speed is important. (Also realizing a book is a dud and stopping after a few chapters.)

[Sirtel]

Originally Posted by hobnail

It's not pretty since all text is the same size, in particular the chapter headings/titles since most books use p tags instead of h tags, and the chapter headings are often right above the first paragraph with no space. But it's a small price to pay for how quick it is to clean a book. I probably download at least 7 free books a week by using ereaderiq.com so speed is important. (Also realizing a book is a dud and stopping after a few chapters.)

It only takes me a minute or two to fix most books, without nuking the existing css. And I often buy the same amount of books in a month as you download via ereaderiq, or more. 50 books per month is not unusual for me. Buying, that is, not reading.

I no longer visit ereaderiq, as most of the free books it advertises aren't particularly good. So I stopped wasting my time with hunting free books. I often do wait for prices to drop, though. I never buy anything over 10€, and usually less than that.

[JSWolf]

Originally Posted by MGlitch

Adobe, which is probably what those librariy books were using, is worse than words per page. It’s bytes. And the developer of it, or one of them anyway, has said it was an arbitrary number of bytes that they basically pulled out of thin air.

But once you get used to RMSDK page numbers, you can get a sense of how long the book is.

[MGlitch]

Originally Posted by JSWolf

But once you get used to RMSDK page numbers, you can get a sense of how long the book is.

The same is true of any page numbering system.

[JSWolf]

Originally Posted by MGlitch

The same is true of any page numbering system.

Not so. If you have 1 page = 1 screen, you have no idea how long the book is because of font sizes, the font, line-height, chapter header wasted space, etc. But the ADE way of doing page number is fairly consistent and ignore all those sorts of things.

[rashkae]

Originally Posted by JSWolf

Not so. If you have 1 page = 1 screen, you have no idea how long the book is because of font sizes, the font, line-height, chapter header wasted space, etc. But the ADE way of doing page number is fairly consistent and ignore all those sorts of things.

As has already been said, the ADE method can very as much as 100%.. so no, it doesn't give you any better indication on the book length.