Firmware 5.0.175773

[JSWolf]

Originally Posted by DNSB

As mentioned often enough, the renderer does not need those spans. They are used to simplify the location system for highlights and notes. The double barrelled kepub.epub extension was intended to simplify deciding which renderer to use.

And ghod alone knows, that you are well aware of the fact that converting ePub to kepub is an extremely easy process to use whether you use calibre, kepubify or any the other solutions that can be found by an simple search.

But why are the spans needed when no other software needs them? I can annotate with RMSDK, Thorium, and BookFusion without any of those spans.

[milady133]

Originally Posted by JSWolf

But why are the spans needed when no other software needs them? I can annotate with RMSDK, Thorium, and BookFusion without any of those spans.

It's not about how different programs are doing it now, it's about what solutions where available when Kobo started offering synching of annotations and bookmarks.

Back then there wasn't a standard solution, it wasn't in ePub2 specifications, so every program developed its solution, and Kobo had to develop something outside of the RMSDK library.
The developers back then decided they needed spans for each paragraph with a unique ID for it to work between different platforms, and once they adopted that solution, other decisions cascaded from that. I'm just speculating, maybe there were other previous decisions that led to developing they're own reading program, but I'm sure it all started because there was something that the RMSDK lacked, and they needed to develop they're own solution. Then they kept adding on that solution because it's easier than working around other company's library. Once you have something you control completely and you can modify as needed it's easier to work on that.

[Falkor]

The 5.x renderer can do highlights and annotations in epub3, so I guess we can consider this problem solved – at some point in the future when 5.x finally becomes usable

I figured out what the problem with full page images is. Apparently SVG dimensions in percent are not supported. Setting the height to "calc (100%–0em)" works fine, presumably because the resulting height is in em and not in %.

[DNSB]

Originally Posted by milady133

I'm just speculating, maybe there were other previous decisions that led to developing they're own reading program, but I'm sure it all started because there was something that the RMSDK lacked, and they needed to develop they're own solution. Then they kept adding on that solution because it's easier than working around other company's library. Once you have something you control completely and you can modify as needed it's easier to work on that.

The pressure to add an ePub3 renderer to Kobo ereaders was based on their purchase by Rakuten and moving into the Japanese market in 2012. If you have never looked at Japanese typography, it is rather complex. Two syllabaries (Hiragana and Katakana), a logographic system (Kanji) and text that can go in multiple directions. Add in features such as furigana (seen as small Hiragana characters placed next to Kanji to give the pronunciation since Kanji often has multiple pronunciations for the same glyph). You will also find quite a few Romanji (Latin alphabet) characters being used. You will notice the 4 names quoted below have the same Kanji but different pronunications.

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

Basically, RMSDK was not capable of handling this and so Kobo licensed the ACCESS NetFront BookReader v1.0 EPUB Edition for use on their devices/apps. Later ACCESS code was done with the Readium project SDK which resulted in the PUBPLUS™ Reader v2.0 EPUB.

Later versions of the Kobo renderer were based on the Readium/webkit and Readium 2 SDKs.

And yes, I strongly suspect that by using their own DRM and servers, Kobo is able to avoid a decent chunk of the cost involved with using Adobe ADEPT DRM and Adobe Content Server.

[JSWolf]

Originally Posted by DNSB

Basically, RMSDK was not capable of handling this

Is the latest RMSDK able to handle this?

[salamanderjuice]

Originally Posted by JSWolf

Is the latest RMSDK able to handle this?

Not on Kobos. The one used by the latest version of ADE is okay at it.

[JSWolf]

Originally Posted by salamanderjuice

Not on Kobos. The one used by the latest version of ADE is okay at it.

I'm not asking about Kobo. I'm wondering if Kobo was to update to the latest RMSDK, would they be able to do away with KePub?

[rantanplan]

Originally Posted by JSWolf

Is the latest RMSDK able to handle this?

The one used in Pocketbook is capable of this.

[salamanderjuice]

Originally Posted by JSWolf

I'm not asking about Kobo. I'm wondering if Kobo was to update to the latest RMSDK, would they be able to do away with KePub?

And I gave you both answers. It does as shown by ADE. I don't think they want to update it. They haven't touched it for years and I imagine they prefer having control over their DRM and features. Avoiding KePub at this point requires going against Kobo's intended workflow and sideloading books. Could they do away with KePub? Yes, would they? Doubt it.

[Falkor]

Well, in 5.x we can see wherer things are going.
We’re getting an updated legacy RMSDK—still old, probably kept for compatibility with Adobe’s DRM.
And a new renderer that opens all kinds of epubs as well as kepub—compatible with LCP DRM.

[kakoo]

Originally Posted by JSWolf

Is the latest RMSDK able to handle this?

If the latest RMSDK is assumed to be equivalent to ADE 4.5, then the answer is no. ADE 4.5 cannot render content correctly when multiple writing directions are mixed within a single HTML file. Because such layouts are common in Japanese publications, RMSDK cannot be considered to meet the standards required for the Japanese market.

[DNSB]

Originally Posted by JSWolf

I'm not asking about Kobo. I'm wondering if Kobo was to update to the latest RMSDK, would they be able to do away with KePub?

The newest ADE I have (4.5.12?) is not capable of some of the features available on Kobo' renderer. Handling ruby is one example. A typical Japanese newspaper page where multiple text directions are mixed in the same page will also look very strange on ADE.

As for doing away with kepub? Kobo is reducing the use of RMSDK in their latest firmware. The only reason for keeping it is for handling Adobe ADEPT DRM. Given that Kobo's Tolino devices already handle LCP and the latest firmware uses Kobo's renderer for everything except ADEPT DRM encumbered epubs, what is the pressure on Kobo to update RMSDK?

[JSWolf]

Originally Posted by DNSB

The newest ADE I have (4.5.12?) is not capable of some of the features available on Kobo' renderer. Handling ruby is one example. A typical Japanese newspaper page where multiple text directions are mixed in the same page will also look very strange on ADE.

As for doing away with kepub? Kobo is reducing the use of RMSDK in their latest firmware. The only reason for keeping it is for handling Adobe ADEPT DRM. Given that Kobo's Tolino devices already handle LCP and the latest firmware uses Kobo's renderer for everything except ADEPT DRM encumbered epubs, what is the pressure on Kobo to update RMSDK?

ADE 4.5.12 is the latest version. I just checked.

[Quoth]

Originally Posted by DNSB

The newest ADE I have (4.5.12?) is not capable of some of the features available on Kobo' renderer. Handling ruby is one example. A typical Japanese newspaper page where multiple text directions are mixed in the same page will also look very strange on ADE.

Typical US Corporate short-sightedness. See also 2007 Kindle and old mobi / KF7 compared to Linux or Windows text handling 7 years earlier!

[rantanplan]

Originally Posted by Quoth

Typical US Corporate short-sightedness. See also 2007 Kindle and old mobi / KF7 compared to Linux or Windows text handling 7 years earlier!

Isn’t kobo a Canadian company?