KOReader: ePub vs kepub, technically speaking

[BiliBug]

The differences of ePub vs. kepub format on a stock Kobo has been debated ad nauseam, and is not what I'm asking here...

Is there a technical superiority between the formats when it comes to KOReader? Does KOReader just strip out and ignore the added spans from the kepub formatted files? Are there any specific KOReader related technical benefits for either format?

I had been converting all books to kepub via Calibre, but now I'm wondering if I'm wasting my time, since KOReader is significantly preferable to the native rendering engines (ePub or kepub) for my taste. Is there a reason to not just leave everything in ePub format if I have no intention of using the stock reader software?

Thanks.

[jackie_w]

I tried out KOReader quite recently (for the first time in many years). FWIW, I couldn't see any point in transferring any books in kepub format unless I also wanted to retain the option to switch between KOReader and stock reading apps on a whim.

As an aside, in the end I decided not to move to KOReader for now. I was very impressed by its great handling of CSS font-variant:small-caps; but put off by its apparent inability to handle font-family:sans-serif;

[Uncle Robin]

Originally Posted by BiliBug

, since KOReader is significantly preferable to the native rendering engines (ePub or kepub) for my taste. Is there a reason to not just leave everything in ePub format if I have no intention of using the stock reader software?

Thanks.

My view is the same as yours, and since moving to KOReader 18 months ago, I have stopped converting to kepub. There is no point. When I first started using KOReader, I seemed to notice a few small quirks in its display of kepubs. I can't even remember what they were, and they may well have been addressed by now, but they were enough to convince me not to bother with kepubs. And that was BEFORE discovering the wonder of gestures - now my most compelling reason not to bother with the stock reader

[NiLuJe]

Yup, waste of time, the extra spans do nothing but waste CPU cycles on both ends .

[NiLuJe]

@jackie_w: For curiosity's sake, what was the use-case behind the sans-serif thing?

(Unless it was as simple as, err, well, making sure stuff renders with a system-preferred sans-serif font?).

I vaguely recall that this hasn't been done so far because it hasn't bothered anybody overmuch, and it would essentially require more UI & code because everything is terrible in the world of font rendering .

(IIRC all the details, this was easier to do for monospace because we actually *know* when a font is monospace ).

[jackie_w]

Originally Posted by NiLuJe

@jackie_w: For curiosity's sake, what was the use-case behind the sans-serif thing?

(Unless it was as simple as, err, well, making sure stuff renders with a system-preferred sans-serif font?).

I vaguely recall that this hasn't been done so far because it hasn't bothered anybody overmuch, and it would essentially require more UI & code because everything is terrible in the world of font rendering .

(IIRC all the details, this was easier to do for monospace because we actually *know* when a font is monospace ).

To add a bit of context, 66% of the 500+ books currently on my main reader contain at least one of the following in the CSS file. :

• font-family:sans-serif;
• font-family:monospace;
• font-variant:small-caps;

(... and yes, I know it's weird that I can quote this percentage )

To answer your specific question. In addition to chapter headings, sans-serif is often used in books trying to simulate passages where characters are communicating via text message, email, social media, etc.

It doesn't seem unreasonable to me that every single reading app should be able to handle those 3 basic, generic style rules. By 'handling' I mean that text using any of them should at least 'stand out' from the main body text and from each other. Additionally all 4 sub-families (Regular, Italic, Bold, BoldItalic) should always display correctly (i.e. no fake italics).

In reality very few apps can handle all 3 (** see note). If you do find one that does and then try to enable its 'select custom font for main body text' option it's almost certain to apply a wrecking ball to those which did work when 'publisher default' (or some such name) was selected.

I'm much less picky about which individual sans-serif/monospace fonts are used than I am about which serif font is used for main body font. Although it would be nice if every app allowed you to specify all 3 rather than just the last one.

In the absence of a full-blown user option in KOReader would it be possible to just assign 'Noto Sans' as a default generic sans-serif font. It should suffice for English and other western European languages but I'm not sure about Cyrillic, Vietnamese etc.

** Note: With enough effort I've always, so far, been able to make my various devices/apps handle all 3 by a combo of calibre driver hacking (on-the-fly CSS tweaking during send-to-device) plus patching on Kobos.


@BiliBug, Sorry, I didn't mean to derail your thread.

[BiliBug]

Originally Posted by jackie_w

…

@BiliBug, Sorry, I didn't mean to derail your thread.

No apology necessary. I appreciate the extra insight.

My sincere thanks to those who have responded thus far.

[NiLuJe]

Originally Posted by jackie_w

In the absence of a full-blown user option in KOReader would it be possible to just assign 'Noto Sans' as a default generic sans-serif font. It should suffice for English and other western European languages but I'm not sure about Cyrillic, Vietnamese etc.

That sounds sensible, although I'm not entirely familiar with the codepaths involved, but I'll forward that to @poire-z .

Thanks, as always, for the detailed answer .

[jackie_w]

Originally Posted by NiLuJe

That sounds sensible, although I'm not entirely familiar with the codepaths involved, but I'll forward that to @poire-z .

Thanks, as always, for the detailed answer .

Thanks for being a catalyst to get this KOR issue fixed. I'm very happy with the new 'Font families' feature.

Now, if only you could get CSS pseudo classes (:first-letter, :first-line) supported, too ...

[NiLuJe]

That unfortunately seems... less likely .

(at a quick glance, the most recent discussion about it happened in https://github.com/koreader/koreader/issues/9142)

[jackie_w]

Originally Posted by NiLuJe

That unfortunately seems... less likely .

(at a quick glance, the most recent discussion about it happened in https://github.com/koreader/koreader/issues/9142)

Thanks for the link. Oh well, I won't get my hopes up.