Quote:
Originally Posted by rashkae
Just the way CSS works. (in conjunction with ADE, which is used by Kobo to display epubs, and which Kobo can only modify in limited ways, per licensing agreements with Adobe.)
It makes perfect sense that Kobo silently appends body {attributes} into an e-book CSS (per user preferences) and ADE uses those as it should to display the books. However, if the body has a class, the values of body.class would then take precedence.
Features are not bugs, even if you don't want them and would rather be without, it's still working as designed. Whether or not this particular idea is bad... I'll leave to the jury. I already said my piece on that.
|
You are wrong again. It's a bug. There's no reason that the font-family in the body cannot be overwritten when a custom font is wanted. None at all. In fact, I've seen other cases with a userstyle.css is used to change the defaults. And what was in userstyle.css was used in place of what was in the book's CSS. So really, it can be done such that this bug doesn't exist. It's not a feature. It's a bug. I'm sorry you feel otherwise, but you are wrong. A bug is not a feature. The problem is that Kobo botched it up in the original two readers and didn't bother to fix it for the Touch.
To be honest, there is a way to fix this bug and it should be fixed. There's no reason to screw up many ePub that come with embedded fonts enabled via the body CSS. Trust me, I've seen publisher ePub that would look silly if the embedded font enabled in the body CSS doesn't work.