Kobo and Footnotes. Again.

[Aleron Ives]

I don't actually use the inline TOC for navigation purposes; I just like to see an overview of the book (number of sections and chapters) before I start reading. I tap the TOC in the menu if I actually need to navigate anywhere.

[Quoth]

Originally Posted by jackie_w

Introducing any wordprocessing app into my epub cleanup workflow seems similarly unnecessary. Editing the epub directly in a proper epub editor works fine, on its own, for me.

Some people are starting with wordprocessor files, that's what I was referring to. Cleaning up a stupidly formatted epub is trivial in Calibre, even to changing the CSS for a Contents Page or Index.

Not all ereaders actually have the system ToC/NCX. Also you might have some sort of specialist contents/index pages not suited to ToC/NCX.

[enuddleyarbl]

Originally Posted by jackie_w

I had a look at your sample epub3. I don't think there is anything wrong with the way you've coded your footnotes/endnotes.

The problem is with your NAV/NCX. Kobos (at least for kepubs) are very picky about TOCs. If you stick to the golden rule for NAV/NCX your Kobo reading life will run more smoothly, i.e. make sure that there is a one-to-one relationship between HTML files in the epub and TOC entries in the NAV/NCX.

Using your sample epub3, as an example:

1. You have one file, plays.xhtml, with 4 entries in the NAV/NCX. You can either reduce the NAV to a single entry of 'Plays' or split plays.xhtml into 4 parts with one NAV entry per part. Whichever method you prefer, do it for all the HTML files which currently have multiple NAV entries
2. You have 2 files, Cover and Jacket which are currently missing from the NAV. Add them.
3. You can leave the inline TOC, toc.xhtml, as-is because the Kobo sees it as "just another chapter" in the book, not its navigation system.

It's possible that item 2 may be less important than item 1 but I'm not sure. I've just enforced the one-to-one rule on all my epubs/kepubs for years.

I've attached an edited version of your sample epub3. Use your normal method of transforming it to kepub and you should see that all the footnotes/endnotes now pop-up as expected.

I checked your modified file out and every single footnote/endnote worked correctly! Not only did they display in a popup, the popups also ended when they were supposed to (many times, when I got a popup before, the footnote just continued on for some random amount of text (possibly to chapter breaks).

I'm going to have to figure out what to do to change my standard editing process.

Thanks! I'm going to add your information to my issue report on Kobo's github page:

https://github.com/kobolabs/epub-spec/issues/59

[jackie_w]

Originally Posted by enuddleyarbl

... many times, when I got a popup before, the footnote just continued on for some random amount of text (possibly to chapter breaks.

Yes, I've seen this, too. Particularly when the Endnotes page contains chapter subheadings to indicate which endnotes belong to which chapter. It looks like Kobo may be using some sort of flawed algorithm to detect where an endnote finishes.

If one is using the epub3 <aside> method it should be obvious that the endnote finishes at the </aside> end tag, no need to read any further text.

However, Kobo does also provide a way to get pop-up footnotes in epub2 (as kepub) using simple <a> tags only. I do wonder if this was why they originally thought they needed an algorithm to detect where the endnote ends.

I can't confirm any of this but it looks as if, maybe, they decide an endnote ends when the next <a> tag or id="..." or href="..." on the page is reached (if any) ???

The reason your sample epub3 didn't have any excess text in its endnotes is that the Endnotes page didn't have any excess text. If the page contains only single-paragraph endnotes there is no excess text to muddy the water.

[mramosch]

I submitted a detailed bug report regarding footnotes/endnotes
on KOBO’s GitHub page that might be of interest to some of you
for working around their problems or further investigating their
issues.

https://github.com/kobolabs/epub-spec/issues/69

[mramosch]

Respective ePubs (1 epub and 1 identical kepub) are attached to
the bug report for refrence.

https://github.com/kobolabs/epub-spec/issues/69


———

[PeterT]

Not meaning to blow your bubble but I doubt that the Kobo developers actually monitor that GitHub repository.

Sent from my Pixel 7a using Tapatalk

[enuddleyarbl]

I don't think Kobo is maintaining their "epub-spec" stuff (I don't even see an indication that they visit it). The last thing that was changed on that site was the README.md file and that was 2 years ago. Everything else has been unchanged for 9 or 10 years. Looking at the Issues, the last one to be closed was 5 years ago. None of the open issues have anyone or anything assigned to them (that I can see). The last Pull Request to be closed was about 7 years ago. One of the two open ones is from a bit over 2 years ago.

I've got to wonder if Kobo even bothers with bug fixes with their firmware. I don't pay all that much attention, but it seems to me that their firmware updates merely add "features" to support new hardware and don't fix anything broken (from a personally biased POV, witness the lack of action on the strikethrough problem and this footnote problem). And, that worries me.

[PeterT]

I've done what I can to make some of the developers aware

Sent from my Pixel 7a using Tapatalk

[mramosch]

Well I started another issue a little earlier and it didn’t take more then 20 minutes and I got a response from Wendy. She may not be a developer but I have seen her on many videos on the NNELS Canada YouTube channel so she seems to be very active with regards to accessibility and standardization. She is always introduced as being part of the KOBO team.

She seemed to be very committed to counter my arguments so she cannot be that far out of the loop. You can have a look at her reply at

https://github.com/kobolabs/epub-spec/issues/68


———

[PeterT]

Yes. Wendy is phenomanal; I've also passed things to her many times including things like books that are poorly marked-up, or do not sync between library loans and Kobo book store.

[mramosch]

So do you think it makes sense at all to report one’s findings there?

Because articulating bugs in an understandable way takes a lot of time that I could definitely make better use of for finding workarounds for all that stuff that doesn’t work.

[PeterT]

Frankly I have no idea. I do know that quite often DNSB or myself will point Kobo devs to threads / posts here; whether it helps get these issues fixed I can't say.

[mramosch]

I see, well, because I am looking for some ‘authority’ that can somehow tell me whether there is at least some probability that KOBO will anytime soon open up

(1) Audio support for non-Kobo-store eBooks (HTML Audio Element) and
(2) JavaScript support like in their iOS app

And I am not talking about some hack-ish kepub file (with some interactive JS scripts) opening when you supply a zipped MP3 container with some hack-ish mp3z file extension ;-)

Otherwise I will stop even thinking about supporting any KOBO proprietary feature at all. All those Shenanigans with half baked solutions like the footnote/endnote stuff is simply annoying. I’d rather focus on supporting features for other platforms that offer more support for Content Creators and Publishers…

[PeterT]

Like any developer I think that before a feature is implemented there has to be some gain to the company in a feature before it is implemented.

Adding support for Audio to non Kobo content will not bring in any revenue from content sales.