Kobo firmware still sucks

[JSWolf]

Originally Posted by FrustratedReader

Android apps are pretty but woeful on book/library management as are all ereaders.

Most Android eBook reading apps are garbage. They don't respect the CSS and are full of options you have to select something instead of being able ot just get on with the CSS. Any reading app that fails to respect the CSS when allowing overrides is garbage. An override should have two sets of options. One for the override and one to turn that specific override off.

Collections are good but they would be better if they allowed collections within collection like a directory tree. Collections have one advantage over directory trees. With collections, you can have the same eBook in multiple collections without having to have multiple copies.

Also despite epub3, kF8 etc vs original mobi prc files and original ereaders with epub, the standards development has been poor tinkering. Stupidity like kepub and KFX doesn't help.

The problem with Amazon is mobi. Amazon still supports mobi for older Kindles. So that stifles the use of the more advanced features of KF8. KFX is ridiculous and has no need to exist. All that KFX can can be done in the renderer for XF8. As for ePub3, the problem there is that the Readers that use RMSDK (ADE) are not updating to the latest version that handles ePub3. So what we get is ePub3 that could just as easiy be ePub2 with no loss of functionality.

[JSWolf]

Originally Posted by jackie_w

As a calibre user, Calibre Companion offers me all the book organisation I'd ever want or need on Android. All the Android epub/pdf reading apps need to be good at is the reading bit.

Which Android reading apps that handle ePub are not garbage? That is, they respect the CSS instead of having just a series or overrides that do not respect the CSS. Do any of them allow selective overrides?

[Lucas Malor]

Originally Posted by JSWolf

As for ePub3, the problem there is that the Readers that use RMSDK (ADE) are not updating to the latest version that handles ePub3.

For what I know, Kobo supports Epub 3. It uses another e-reader app for Epub 3 and Kepub, that supports Epub 3 too. I don't remember the name of the e-reader app.

[JSWolf]

Originally Posted by sickntwisted

The battery life on the Kobo Aura is way better than on the Kindle, according to my usage.

And one huge flaw the Kindle has is that there is no want to turn it off. So if you know you won't be using your Kindle for some time, it will sit there and slowly drain. A Kobo, you can turn off. If you have a second Kindle, the one you don't use will be sitting put away with a dead battery unless you remember to charge it. Your unused Kobo can be left turned off.

[geek1011]

Originally Posted by JSWolf

Which Android reading apps that handle ePub are not garbage? That is, they respect the CSS instead of having just a series or overrides that do not respect the CSS. Do any of them allow selective overrides?

I personally like Lithium along with a few mods I made (dictionary, chapter progress, custom fonts, series metadata, and lower minimum font size, plus a few other tweaks). PM me if you want me to send you them.

[jackie_w]

Originally Posted by JSWolf

Which Android reading apps that handle ePub are not garbage? That is, they respect the CSS instead of having just a series or overrides that do not respect the CSS. Do any of them allow selective overrides?

Both PocketBook (by Obreey) and Bookari (aka Mantano) work well enough to keep me happy - and I'm quite picky.

PocketBook is completely free, even though it has many features often found only in paid-for versions of other apps, so the best thing for you to do is just try it yourself. It does have a slightly quirky user interface so some features aren't always immediately obvious. It also has a per-book choice of 2 renderers (Adobe-based or Webkit-based) the latter will happily honour some CSS that the former won't, e.g.
- font-variant:small-caps (simulated, unless you use a few tricks to reference a sideloaded true small-caps font)
- pseudo-selectors, such as first-letter, first-line
- boxes with rounded corners
... ... probably many more.

I don't know what CSS you're particularly interested to preserve but the usual suspects (dropcaps, raisedcaps, blockquotes, embedded fonts) display just as well on my smartphone as they do on my Kobo.

Bookari also has a per-book choice of 2 renderers, one is the usual Adobe-based variety, the other is aimed at EPUB3. I haven't used the EPUB3 one enough to critique it. All my EPUB3 books work quite happily in the older Adobe-based renderer. I've had Bookari Premium version for years so I don't know which features are missing from the free version.

[lumpynose]

In addition to PocketBook and Bookari there's koreader for android. It's not available from the google play store but you can download its apk, the link for which is given in the koreader thread here on mobileread.

In the combined books I've made the CSS isn't very complicated but I do use CSS combinators; plus, greater than, and space, and have ones that are nested 3 deep. Things went haywire in a jiffy with the android readers often recommended here; librera and moon+ but they looked perfect with PocketBook (thanks go to jackie_w for recommending it) and koreader. Unfortunately my Nexus 9 is giving up the ghost and I need to replace it.

[JSWolf]

Originally Posted by Lucas Malor

Few? There are dozen of bugs and reporter. And the people I see that continues to defend Kobo firmware like it was a sacred reliquary are three here.

But even if there is only one woman/man that is unsatisfied, this woman/man must be listen. Here, in a democratic state, everywhere. It's not democratic saying "it works for me", "I don't need it", "if you don't like this country, leave"

I forget what exactly the bug was, but there was one firmware version that did have a bug with the SD card where it would scan it excessively. That has since been fixed.

[JSWolf]

Originally Posted by rashkae

3. In Kepub, measurements of physical length are translated to a fixed number of pixels. For a very common example, text-indent 20pt. The number of pixes were adjusted back when devices were 160PPI,,,, on a 300PPI device, 20pt indent is barely distinguishable.

That's really poor eBook making to use pt instead of em. 20pt is about 1.6em. Using 1.6em is what works and is proper coding. You cannot know what type of screen/program/system the eBook will be read with so using em will handle this.

4. In Kepub, page numbering for the whole book jumps around out of order on some books (ie, display progress for whole book instead of per chapter). This is related to the reader using TOC entries instead of the epub spine to determine page numbers, and I realize you're only likely to see on 'unsupported' kepub sideloaded books. But there's no reason for it!.. the calculation for progress by Percent got it right, it should be possible to get page number ordering using the same logic.

This is not a bug. If you convert an ePub that does not follow the ToC conventions for kepub, that's your fault, not Kobo.

5. For epub books, the font used does not fall back if the text has missing glyphs... for books that take advantage of Unicode characters, this means those characters will be missing entirely from the text, even if Kobo fully supports it. (Works fine with Kepub)

This again is not a bug. If you chose to use a font that does not support the glyphs in the ePub, that is again your fault. If the ePub has font(s) embedded that handle the glyphs and you override that, again, your fault. Only if the ePub does not have an embedded font that works or the default ePub font doesn't work can it be considered a problem.

[JSWolf]

Originally Posted by Sarmat89

That's not stupidity. EPUB format is too complex to be parsed and rendered by an embedded device, so it must be preprocessed into a less taxing form, like predictable-structure kepub or lightweight binary KFX.

kepub is not preprocessed. It's still text readable unlike KFX. ePub is processed on the fly and does what KFX does in terms of typesetting. Since ePub can do it with the renderer, there's no reason KF8 cannot do the same thing. That's why there is no need for KFX. What does KFX do in terms of features that cannot be done with KF8 and the renderer (if it was written to do it)?

[rashkae]

Originally Posted by JSWolf

That's really poor eBook making to use pt instead of em. 20pt is about 1.6em. Using 1.6em is what works and is proper coding. You cannot know what type of screen/program/system the eBook will be read with so using em will handle this.

Very incorrect statements.

pt, like in, is a physical distance measurement. It is absolutely possible to know what DPI a screen in, and for the reader to calculate the correct number of pixels to represent the correct distance. Not only is it possible, but the adobe Epub reader does it just fine.

Since pt is a actual distance which is not related to font size, it has no similarity to any value in em.

[JSWolf]

Originally Posted by Lucas Malor

For what I know, Kobo supports Epub 3. It uses another e-reader app for Epub 3 and Kepub, that supports Epub 3 too. I don't remember the name of the e-reader app.

But other Readers using RMDSK do not use a second renderer for ePub3. That means they rely on RMSDK and that's not always kept current.

[JSWolf]

Originally Posted by rashkae

Very incorrect statements.

pt, like in, is a physical distance measurement. It is absolutely possible to know what DPI a screen in, and for the reader to calculate the correct number of pixels to represent the correct distance. Not only is it possible, but the adobe Epub reader does it just fine.

Since pt is a actual distance which is not related to font size, it has no similarity to any value in em.

I'm not saying that you cannot use pt, but hat you should not use pt as it's sloppy coding. As you can tell, pt is not always properly rendered. IT's not just a Kobo issue. So use em and you'll have things properly rendered.

[Quoth]

em is best. Though 12 pt is supposed to be rendered as 1em.
I wonder will Calibre add a check box to convert all "pt" references to "em" references?

[lumpynose]

Originally Posted by rashkae

Since pt is a actual distance which is not related to font size, it has no similarity to any value in em.

In addition to em there's also rem, root font em. There was a thread here, if I remember correctly, about how an em can change when you're using different sizes where things are nested; e.g., a p inside of a blockquote perhaps. I didn't pay attention and don't remember the details. I remember thinking that maybe rem could avoid the variance.