kepub: why does it exist?

[GrandNeko40]

i suppose i don't have a "real" reason for asking this question, other than to satisfy my curiosity. but i know that people generally seem to prefer reading kepubs on a Kobo, over the standard epub. i know that Kobo's reader parses or renders kepubs differently than it does epubs. kepub enables features like inline or popup footnotes/annotations, chapter length estimations, and so on. so my question is this:

what's the technical reason for this? is it that Kobo handles epubs poorly or incorrectly? that is to say, do other devices support such additional features on a bog-standard epub, where Kobo has made a decision not to, in favor of their own extension to the format?

i'm just sort of wondering what's the point of the kepub in the first place. is it an anachronistic relic, left over from a time when the epub format specification was deemd lacking, and Kobo created an enhancement that they just haven't gotten around to abandoning?

[DNSB]

Kobo introduced kepub originally using the ACCESS renderer for rendering epub3 Japanese language ebooks since at that time, Adobe's RMSDK was rather poor (and I am being kind at saying rather poor) at rendering ePub3. Even the latest RMSDK still lags the Webkit based renderer that Kobo now uses in many ePub3 features. OTOH, to manage ebooks using Adobe's ADEPT DRM which is very common, Kobo had to either write their own code for managing ADEPT DRM or continue using RMSDK.

Personally, I use the standard ePub for most books since it has (IMNSHO) superior font and typography management. For those few ePubs where there are multiple large images, I will convert to kepub to allow use of it's ability to zoom images. A very small subset of the ePubs I own are ePub3 FLO (fixed layout) ebooks where the WebKit based renderer handles them much better than RMSDK (again being kind to RMSDK).

Another reason for kepub is that it uses Kobo's own DRM which saves them from paying Adobe for any ePubs synced to your ereader/app directly from Kobo.

BTW, if you ever want to get a headache, take a look at Japanese typography where you can use right to left or left to right, top to bottom or horizontal lines with 4 different sets of glyphs (native Hiragana, Katakana, and Kanji plus for other languages Rōmaji). Add in ruby for such things as giving the pronunciation of Kanji since Kanji ideograms can have multiple pronunciations.

One example of Kanji where ruby would be used would be the 4 women's names below:

• 淳子 (Akiko)
• 淳子 (Atsuko)
• 淳子 (Junko)
• 淳子 (Kiyoko)

[slm]

Originally Posted by DNSB

Kobo introduced kepub originally using the ACCESS renderer for rendering epub3 Japanese language ebooks
Another reason for kepub is that it uses Kobo's own DRM which saves them from paying Adobe for any ePubs synced to your ereader/app directly from Kobo.

My memory may be going, but I think Kobo had kepubs long before it was the company was bought by Rakuten and long before I had ever heard of epub3.

I always thought the reason for kepub was that when Kobo delivers the kepub it doesn't owe Adobe anything.

[DNSB]

As far as I recall, Kobo entered the Japanese marker with the Touch in late 2011. Rakuten bought Kobo in January 2012 and two more Kobo ereaders (Glo & Mini) were introduced to the Japanese market later that year. As far as the Touch was concerned, I think FW 1.9.12 in October 2011 was the first one that supported kepub.

[JSWolf]

Originally Posted by GrandNeko40

i suppose i don't have a "real" reason for asking this question, other than to satisfy my curiosity. but i know that people generally seem to prefer reading kepubs on a Kobo, over the standard epub. i know that Kobo's reader parses or renders kepubs differently than it does epubs. kepub enables features like inline or popup footnotes/annotations, chapter length estimations, and so on. so my question is this:

what's the technical reason for this? is it that Kobo handles epubs poorly or incorrectly? that is to say, do other devices support such additional features on a bog-standard epub, where Kobo has made a decision not to, in favor of their own extension to the format?

i'm just sort of wondering what's the point of the kepub in the first place. is it an anachronistic relic, left over from a time when the epub format specification was deemd lacking, and Kobo created an enhancement that they just haven't gotten around to abandoning?

The real reason Kobo has KePub is because they won't update the version of RMSDK used on Kobos. RMSDK is the underlying software for Adobe Digital Editions. If Kobo updated RMSDK to the latest version, they would have no need for KePub.

[DNSB]

Originally Posted by JSWolf

The real reason Kobo has KePub is because they won't update the version of RMSDK used on Kobos. RMSDK is the underlying software for Adobe Digital Editions. If Kobo updated RMSDK to the latest version, they would have no need for KePub.

John, have you actually done any testing with ePub3 ebooks and the latest version of RMSDK?

[Aleron Ives]

Since KEPUB is just EPUB with extra span tags, the real question is why those tags are necessary. Are they used to calculate the 1 screen = 1 page metrics? Things like highlighting work fine in RMSDK without needing the extra span tags, so I don't really understand why KEPUB needs them, unless Kobo's WebKit implementation is just bad.

[DNSB]

Originally Posted by Aleron Ives

Since KEPUB is just EPUB with extra span tags, the real question is why those tags are necessary. Are they used to calculate the 1 screen = 1 page metrics? Things like highlighting work fine in RMSDK without needing the extra span tags, so I don't really understand why KEPUB needs them, unless Kobo's WebKit implementation is just bad.

The explanation I once got is that the extra spans simplified the task of selecting text. This dates back to the ACCESS renderer.

[deleted2]

As far as I know, and from what I've read on the web from other users, KePub are faster and more accurate about the time left in chapters, among other benefits. I don't see why people are still using ePub with Kobo. Everyone have some esoteric reasons like the fonts looks better. I've never seen any difference.

[Sirtel]

Originally Posted by Claude_C

Everyone have some esoteric reasons like the fonts looks better. I've never seen any difference.

On anything smaller than 8'' the epub renderer does a better job with word spacing. That's the main reason I use epubs on my Libra 2 (and kepubs on the Sage). I read fully justified text without hyphenation, so I definitely notice the difference in word spacing, even with the relevant kepub patch. Someone who reads left-aligned or hyphenated text might not see any differences.

[Aleron Ives]

What does "better job" mean in this context? I don't see any weird spacing between words on my Libra. I know that if you enable ligatures you can get weird spacing between the letters of a word, but I use the default rendering mode (optimizeSpeed), which doesn't have that problem.

Also, how do you disable hyphenation, anyway? Do you replace the default hyphenation dictionary with an empty one somehow?

[Sirtel]

Originally Posted by Aleron Ives

What does "better job" mean in this context? I don't see any weird spacing between words on my Libra. I know that if you enable ligatures you can get weird spacing between the letters of a word, but I use the default rendering mode (optimizeSpeed), which doesn't have that problem.

Also, how do you disable hyphenation, anyway? Do you replace the default hyphenation dictionary with an empty one somehow?

I also use optimizeSpeed. What I mean is that the epub renderer is capable of micro-justification, which makes the word spacing more even and less noticeable with fully justified, non-hyphenated text. The kepub renderer doesn't do micro-justification, and so the spacing between words might get rather large in some cases, if you don't use hyphenation. Especially on smaller screens.

I disable hyphenation in the book css (yes, every book; I edit them all anyway, so disabling hyphenation is only a very small additional chore). First I remove the code that's related to hyphenation in the css and after that I add the following to the body css:

-epub-hyphens: none;
adobe-hyphenate: none;
-webkit-hyphens: none;
-moz-hyphens: none;
hyphens: none;

[geek1011]

Originally Posted by Aleron Ives

Since KEPUB is just EPUB with extra span tags, the real question is why those tags are necessary. Are they used to calculate the 1 screen = 1 page metrics? Things like highlighting work fine in RMSDK without needing the extra span tags, so I don't really understand why KEPUB needs them, unless Kobo's WebKit implementation is just bad.

Developers probably got overwhelmed by EPUB CFIs and other stuff (it is a bit daunting at first, and somewhat easy to do incorrectly) and decided that they'd just add spans so it's easier to get locations without walking around stuff (just get the element at a point, then get the nearest span), and to provide some theoretical flexibility around updating the content of a book.

[geek1011]

Originally Posted by DNSB

The explanation I once got is that the extra spans simplified the task of selecting text. This dates back to the ACCESS renderer.

That would make sense since selections are done by an element and an offset, and having the deepest element always being a span makes it really simple to encode/decode selections.

[geek1011]

Originally Posted by Claude_C

Everyone have some esoteric reasons like the fonts looks better. I've never seen any difference.

Adobe's renderer does objectively support a wider range of font features. OTOH, if Kobo were to update webkit to a more modern version, there wouldn't really be any advantage of RMSDK anymore (plus they wouldn't have to keep dealing with web stuff breaking...).