Kobo Bug thread

[davidfor]

Originally Posted by masterz87

the battery life thing is simple, I have wifi _always_ off except really rarely when i decide to use pocket maybe once a week or less. Furthermore the battery life thing I did, I _only_ read epubs no cbz I only did a test with cbzs lately

OK, the CBZ stuff doesn't apply, but the rest does. The faster you read a page, the more page turns, the faster the battery is drained.

and they also seem to _not_ use the orientation of the images themselves. It seems tot take whatever the dimensions of the cover(aka first image) and rotate it to fit the screen best.

Yes, I believe this is correct. I tend to agree it isn't good, but I could see that others would complain they have to keep rotating the device a the image changed dimensions.

Also this thing changes pages _slower_ than my NST so I'd hardly call it a "fast" ereader the lag in the UI is similar or worse than the NST I had previously. it had a 800mhz cpu and I think 256MiB of ram and was running android 2 with the entire UI/reading app etc was all done via java.

I don't think I have ever seen any claims that the Kobo devices are fast. I'll agree that it isn't fast, but I don't have any real problem with it.

[masterz87]

Originally Posted by davidfor

OK, the CBZ stuff doesn't apply, but the rest does. The faster you read a page, the more page turns, the faster the battery is drained.

Yes, I believe this is correct. I tend to agree it isn't good, but I could see that others would complain they have to keep rotating the device a the image changed dimensions.


I don't think I have ever seen any claims that the Kobo devices are fast. I'll agree that it isn't fast, but I don't have any real problem with it.

I have the text size at barely more than minimum and having "show epub page numbers" shows that I have ~2-3 pages per page so it's clearly going to be slower than most things. I think that it's ~6min per page or something.

The NST I was told from CS staff that the rating is based upon the following information.

1 page turn per 2 minutes and thus they had 30hrs total from 30 minutes of that reading per day for 2 months thing.

Edit: Also do kepubs use less power or something on the kobo? Because I don't know why people would be recommending to use that over standard ones.

[Rev. Bob]

Originally Posted by davidfor

And comparing the battery usage to others is a bit hard. It depends so much on how you use the device. While reading, the power usage is basically when turning the page. While you are reading the page, the CPU will go into a low power mode, and use very little power. So, a slower reader will get more battery life than a fast reader.

Originally Posted by masterz87

Also this thing changes pages _slower_ than my NST so I'd hardly call it a "fast" ereader the lag in the UI is similar or worse than the NST I had previously.

He's talking about you being a fast or slow reader, not the machine...

Originally Posted by masterz87

Edit: Also do kepubs use less power or something on the kobo? Because I don't know why people would be recommending to use that over standard ones.

Different rendering engine. Personally, I don't care (a good ebook should render well in either one), but some people prefer one over the other.

[davidfor]

Originally Posted by Rev. Bob

He's talking about you being a fast or slow reader, not the machine...

I didn't even think of that interpretation. It would explain the comment.

@masterz87: Yes, I am talking about the users reading speed and hence how often they need to turn the page. The faster the reading speed, the more often the page is turned, the higher the power usage and the lower the battery runtime,

Different rendering engine. Personally, I don't care (a good ebook should render well in either one), but some people prefer one over the other.

Yes, the kepub renderer seems to be faster than the RMSDK epub renderer. I have no idea if this helps with the battery life, but the people who think the page turns are to slow when reading an epub, usually think the kepub renderer is good enough. Personally, I find the epub page speed enough. It works out to be about how long it takes for me to move my eye from the bottom right to the top left, so that's all I need. If I was going to convert to the kepub renderer, it would be because of the in-book stats. I love the chapter chart as a way of seeing where I am in the book.

[Rev. Bob]

Originally Posted by davidfor

The faster the reading speed, the more often the page is turned, the higher the power usage and the lower the battery runtime

I'd imagine the total number of page-turns wouldn't change that much with reading speed, though - it's just a matter of how quickly you use 'em up. If anything, I'd expect a speed-reader to eke out a few more turns because they're not losing the power used for system housekeeping (the clock, wifi signal, et al.) and thus a higher amount of the battery goes toward actually handling the screen.

This is also why I like lean, streamlined books that don't have tons of CSS rules stacked up on top of each other. That complexity eats processing power and kills your battery life in the process!

Originally Posted by davidfor

If I was going to convert to the kepub renderer, it would be because of the in-book stats. I love the chapter chart as a way of seeing where I am in the book.

True, that would be nice - but I've gotten accustomed to thinking in percentages anyway. What I'd really like is an "X pageturns left in chapter" display, like iBooks has on my iPad. That way, it'd be easier for me to decide whether to read One More Chapter or put the book down for the night...

[robko]

Originally Posted by Rev. Bob

I'd imagine the total number of page-turns wouldn't change that much with reading speed, though - it's just a matter of how quickly you use 'em up. If anything, I'd expect a speed-reader to eke out a few more turns because they're not losing the power used for system housekeeping (the clock, wifi signal, et al.) and thus a higher amount of the battery goes toward actually handling the screen.

That sounds plausible, but they were talking total HOURS read. So you might get the same or more page turns on a charge, but if you're a fast reader you could burn through them in 6 hours while someone else might burn through the same number of turns in 12 hours. That's where fast vs slow really comes into play.

[davidfor]

Originally Posted by Rev. Bob

I'd imagine the total number of page-turns wouldn't change that much with reading speed, though - it's just a matter of how quickly you use 'em up. If anything, I'd expect a speed-reader to eke out a few more turns because they're not losing the power used for system housekeeping (the clock, wifi signal, et al.) and thus a higher amount of the battery goes toward actually handling the screen.

Maybe I should have said "faster the battery usage".

True, that would be nice - but I've gotten accustomed to thinking in percentages anyway. What I'd really like is an "X pageturns left in chapter" display, like iBooks has on my iPad. That way, it'd be easier for me to decide whether to read One More Chapter or put the book down for the night...

Which is what the kepub renderer does. It's page count is actually screens count and changes with the font and other settings. And the count is for the current chapter. There is an option to show it for the full book, but that uses a method similar to epubs.

[sherman]

One annoyance I've found lately is that the version of RMSDK used on the current firmwares seem to hate '!important' CSS.

RMSDK seems to consider it invalid CSS, and we all know how RMSDK handles "invalid" CSS...

I don't recall it being an issue on earlier firmwares, but it definitely seems to be a thing on 3.19+

I encountered a book which used !important in its CSS today, and I was (figuratively) tearing my hair out trying to figure out why the CSS wasn't displaying. Finally narrowed the issue down to the !important.

[Rev. Bob]

Originally Posted by sherman

I encountered a book which used !important in its CSS today, and I was (figuratively) tearing my hair out trying to figure out why the CSS wasn't displaying. Finally narrowed the issue down to the !important.

I regard !important in CSS as akin to GOTO statements in structured programming languages - technically permissible, but chances are excellent that if you're using them, you've gone very far astray and it's time to rethink your approach.

I may have encountered a couple of situations where !important truly was necessary, but none come to mind. The cases I think may have used that hack were large websites where pages used multiple layers of stylesheets - which makes sense in that context, but no ebook should be doing that.

[JSWolf]

Of all the eBooks I've looked at the code, I've never seen !important or have I ever used it. I see no reason for it.

[DNSB]

Originally Posted by JSWolf

Of all the eBooks I've looked at the code, I've never seen !important or have I ever used it. I see no reason for it.

I've seen !important used in 3 ebooks. I would agree with Rev. Bob that it was unnecessary. In the case of one ebook, it had 8 stylesheets (one for the cover page, one for the titlepage, one for chapters, one for table of contents, one that was basically pagestyles.css and a couple of more for miscellaneous content. The 8th stylesheet which had the !importants was used to try to cover the sins of commision and omission in the other 7 -- lipstick on a pig.

It took about 40 minutes to convert the stylesheets into a single stylesheet, get rid of multiple repeated images -- did we really need the identical graphics for the chapter title repeated for each chapter, convert absolute sizes into relative sizes and otherwise clean things up.

[JSWolf]

Originally Posted by DNSB

I've seen !important used in 3 ebooks. I would agree with Rev. Bob that it was unnecessary. In the case of one ebook, it had 8 stylesheets (one for the cover page, one for the titlepage, one for chapters, one for table of contents, one that was basically pagestyles.css and a couple of more for miscellaneous content. The 8th stylesheet which had the !importants was used to try to cover the sins of commision and omission in the other 7 -- lipstick on a pig.

It took about 40 minutes to convert the stylesheets into a single stylesheet, get rid of multiple repeated images -- did we really need the identical graphics for the chapter title repeated for each chapter, convert absolute sizes into relative sizes and otherwise clean things up.

That is very excessive. I've never seen 8 CSS in one eBook. But I have seen the duplicate graphics for things like chapter header ornaments and section breaks. It's just crazy how poorly some publishers make eBooks. But at least with some experience, it's not too much of a hassle fixing things.

[Rev. Bob]

Originally Posted by DNSB

The 8th stylesheet which had the !importants was used to try to cover the sins of commision and omission in the other 7 -- lipstick on a pig.

That's typically been my experience, that !important is used as a crude patch by people who can't or won't take the time to go back and do it right.

Originally Posted by JSWolf

That is very excessive. I've never seen 8 CSS in one eBook.

Usually, when I see something like that, it's for an omnibus that was literally made by taking the existing ebooks and shoveling them together into one file. I was dealing with that a little while back, when there were four books in a series and the publisher had made a 4-in-1 package out of 'em.

Tor.com's "Some of the Best of" anthologies do the same thing, and I've seen some indie short story collections where the author published the stories separately at first, then rolled 'em up into a bigger book. So I can see how it can come to pass as a quick and dirty solution. (Pretty quick, but very dirty.) This is why I like the "house stylesheet" approach that some of the Big Five take, although it'd be nice if they'd take the step of weeding out the unused rules before distribution. At least it makes combined books easier to put together, I guess.

Anyway, it's not too hard to unravel if you're careful about it, but you do have to watch out for class names that are reused between CSS sheets but change meanings along the way. For example, calibre2 might be "standard body text" in one book but "chapter title text" in another. I usually respond to that in an omnibus by splitting the books into new ebooks, renaming the classes (such as by putting a "bk1_" at the beginning), then recombining them. Once that disambiguation's done, it's usually easy to merge the stylesheets and combine the classes that do the same things. I think calibre has a merge function now that may make that easier, but I haven't tried it out yet.

Frankly, I wish there were some kind of standards for ebook styling. The web tech has general expectations and ebook readers have default values; that shouldn't be a big ask. I'm not even talking about the picky stuff, just "set your body text to 'medium' instead of 'small' or some weird percentage" for a start.

[JSWolf]

There should be standards as to how eBooks are formatted. This would give the settings options a better chance of working and a better chance of getting eBooks to look how we want.

Given that Kobo has a font, font size, margins, & line-height settings, having eBooks made so these work well would be best. I would like no margins, no excessive space wasted for chapter titles, no line-height except as needed, no embedded fonts except as needed, no paragraph spaces, indents of 1.2-1.5em, & no excessive space for offset text. That would mean that settings options in eBook sfotware would work that much better.

[Rev. Bob]

Originally Posted by JSWolf

Given that Kobo has a font, font size, margins, & line-height settings, having eBooks made so these work well would be best.

I am staunchly opposed to any set of standards designed around any one company's platform.

Originally Posted by JSWolf

I would like no margins, no excessive space wasted for chapter titles, no line-height except as needed, no embedded fonts except as needed, no paragraph spaces, indents of 1.2-1.5em, & no excessive space for offset text.

Taking these one at a time:

- "No margins." On anything? Bad idea. If nothing else, the existing HTML specs define certain default margins; devices should adhere to those rather than defining a new set of defaults that results in contradictions. We'd have the browser wars all over again.

- "No excessive space." Useless, since "excessive" is a subjective definition.

- "No line-height." Setting line-height to zero instantly makes all text unreadable, if strictly implemented. Omitting the parameter for standard-size text is something I can get on board with, but particularly with Kobo, not setting line-height when changing font size is a recipe for disaster. (Ever seen headers that overlap when the text wraps to a second line? That's why that happens. Setting line-height to "normal" when resizing text fixes that.)

- "No embedded fonts except as needed." Please define "need." It's one thing to define it functionally ("I need to display some emoji characters."), but some people will define it cosmetically ("I need to use this font to convey this style.").

- "No paragraph spaces." Back to the browser wars, I see.

- "Indents of 1.2-1.5em." A range is not a number, so here you're getting into "best practices." I agree that paragraph indents should be around that mark - I use 1.5em, myself - but I would strongly resist making that a default value in the reader.