Firmware 5.0.175773

[Falkor]

They advertise ePub3 as a supported format, though. Kinda misleading.

[PeterT]

Possibly because the extra spans are used by the kepub engine to track location within the book.

[Quoth]

Originally Posted by PeterT

Possibly because the extra spans are used by the kepub engine to track location within the book.

So I've read, but that makes no absolute sense, because the ADE notes work. No-one else uses kepub, yet there are epub2 and epub3 renderers that do annotation too.

[JSWolf]

Originally Posted by Quoth

So I've read, but that makes no absolute sense, because the ADE notes work. No-one else uses kepub, yet there are epub2 and epub3 renderers that do annotation too.

So why can't Kobo do away with the extra KePub code as it's the only renderer that needs it?

[Quoth]

Originally Posted by JSWolf

So why can't Kobo do away with the extra KePub code as it's the only renderer that needs it?

Answers on the back of a postcard to Kobo.

It's baffling, but doesn't bother me. It's easier to understand why KFX exists (which is entirely to suit Amazon).

[DNSB]

Originally Posted by Quoth

It's odd. Why should the kepub renderer need the extra spans for the notes to work?

Originally Posted by JSWolf

It's always been that way. My guess is to keep people buying eBooks from Kobo if they want to use the KePub renderer.

The spans are used for location information for the notes and bookmarks within the ePub book when using the kepub renderer. It simplifies managing the location information and allows highlighting and taking notes across page boundaries.

As for guessing this is to limit people to purchasing books from Kobo? Considering that various tools to add the spans to ePub ebooks have been available very shortly after Kobo back in 2012 started using the ACCESS NetFront BookReader v1.0 EPUB Edition to allow handling Japanese typography and ePub3, purchasing an ebook from almost anywhere and converting it to an ePub with the Kobo spans is pretty trivial. Heck, calibre even has that capability built in to the KoboTouch driver now.

[DNSB]

Originally Posted by Falkor

They advertise ePub3 as a supported format, though. Kinda misleading.

Misleading? Kobo's renderer (originally the ACCESS NetFront BookReader v1.0 EPUB Edition renderer which ended up being donated to the Readium project and moving on to their current Readium/webkit based version) has excellent ePub3 support for both reflowable and fixed layout ePub3s.

Yes, the RMSDK renderer has very poor ePub3 support since Kobo has not updated that renderer in quite a while. For the most part, the RMSDK renderer is being used to allow support for Adobe ADEPT DRM protected ePubs. OTOH, virtually all the ePub3 ebooks using more advanced features display without issue on the Kobo webkit-based renderer.

One example is the British Library's Harry Potter: A Journey Through a History of Magic. When I picked it up in 2017, it looked good in Thorium on my desktop and as a kepub on my Kobo ereaders. My first test was simply to rename the file extension to .fxl.kepub.epub to trigger the Kobo renderer as an ePub3 fixed layout which worked well though notes/highlights did not work. A conversion using kepubify looked as good and allowed the notes/highlights functionality.

[PeterT]

I can't help but think part of the rationale for not using Adobe's DRM for all content was financial; I expect Adobe have a fairly high cost per book fufilled with their DRM

[JSWolf]

Originally Posted by PeterT

I can't help but think part of the rationale for not using Adobe's DRM for all content was financial; I expect Adobe have a fairly high cost per book fufilled with their DRM

My thought is so you'll buy eBooks from Kobo so you'll know they will work properly.

[Falkor]

Originally Posted by DNSB

Misleading? Kobo's renderer (originally the ACCESS NetFront BookReader v1.0 EPUB Edition renderer which ended up being donated to the Readium project and moving on to their current Readium/webkit based version) has excellent ePub3 support for both reflowable and fixed layout ePub3s.

That's my point. Support is pretty good and the device supposed to be compatible, but it doesn't actually open ePub3s with Kobo’s renderer. it opens them with an old RMSDK that has disastrous error handling.

Originally Posted by JSWolf

My thought is so you'll buy eBooks from Kobo so you'll know they will work properly.

That might also explain why they keep using their old RMSDK for so long and haven’t switched to the more forgiving one that they use in 5.x earlier.

[Quoth]

Originally Posted by Falkor

That's my point. Support is pretty good and the device supposed to be compatible, but it doesn't actually open ePub3s with Kobo’s renderer. it opens them with an old RMSDK that has disastrous error handling.

You can rename them as discussed, if you don't need highlights and notes. I'd almost never use annotation on novels unless I have the odt/docx source and I'm proofreading.

[compurandom]

Originally Posted by Quoth

It's odd. Why should the kepub renderer need the extra spans for the notes to work?

It uses the extra spans with unique ids as anchors for the bookmarks and highlights.

It's easy enough to run it through one of the converters (like calibre) to add them in for any epub. Someone put out a stand alone converter as well.

Originally Posted by JSWolf

My thought is so you'll buy eBooks from Kobo so you'll know they will work properly.

Nope, that's not it at all.

[JSWolf]

Originally Posted by compurandom

Nope, that's not it at all.

Then why is the KePub rendered on a Kobo Reader the only ePub3 software that needs these spans when every other program does not need them?

[Quoth]

Originally Posted by compurandom

It uses the extra spans with unique ids as anchors for the bookmarks and highlights.

Yes. I can easily make a real kepub, though I don't like the kerning on that renderer and other renderers don't need the extra spans for annotation. I've many apps, programs and actual eink models that are not Kobo as well as Kobo eink.

I know that's how it works and I've edited kepub, but it seems like an odd design.

[DNSB]

Originally Posted by JSWolf

Then why is the KePub rendered on a Kobo Reader the only ePub3 software that needs these spans when every other program does not need them?

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.