Quote:
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.
…
…
…
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.
|
Quote:
Originally Posted by enuddleyarbl
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 |
In order to learn more about the KOBO footnote/endnote problems I checked the original and Jackie_w’s edited version myself.
I am on a Clara BW with firmware 4.41.23145 (637199291b, 10/29/24)
and it
does NOT work entirely correctly.
What does NOT work:
The upstream-references to the footnotes/endnotes DO show a pop-up with the correct text of the respective footnote/endnote, however the backlink from the footnote/endnote back to the reference in the text does ALSO (unexpectedly IMHO) open up a pop-up with a string starting at the exact location where the upstream-link is positioned in the text BUT not stopping until it reaches the next upstream-link in the text.
In case of the last upstream-link (or when there is only one single footnote/endnote in the chapter) the string in the pop-up will continue until the end of the chapter.
The erroneous string will swallow footnotes (or even collectively all endnotes positioned at the end of the chapter - like in your ‘
footnotes_at_chapter_end.xhtml’ example) until it reaches the next upstream reference (or end-of-chapter/file).
What DOES work:
The ONLY place where (almost*) everything really works as expected is when you have your endnotes in a different file/chapter like in your ‘
footnotes_as_endnotes.xhtml’ example. Here the upstream-links point and navigate correctly to the ‘
endnotes.xhtml’ file and the backlinks do NOT force-show a pop-up but go rather straight back to the correct position in the ‘
footnotes_as_endnotes.xhtml’ file.
(almost*) -> because the navigation menu opens automatically when linking cross-file, so you have to tap first to get rid of it in order to view the whole page of endnotes.
The only difference in the format of your cross-file upstream-links and back-links is that, instead of pointing to the target id only (#id), they have the file name preceding them (file_name.xhtml#id).
So I added preceding file names to your ‘
footnotes_at_chapter_end.xhtml’ backlinks but it didn’t change anything in their wrong behavior, still showing the pop-up with string continuing until reaching the next upstream-link or end-of-chapter/file.
What’s the problem?
The reason that the back-links do not work correctly is because they are positioned within a paragraph.
From some other bug report on the ‘allegedly abandoned’ KOBO GitHub page we know that KOBO suggests a hack, where they want us to insert <div></div> pairs in front of every paragraph with a reference to a footnote and then backlink to the <div> from the actual footnote/endnote.
But that is very problematic for many reasons!
Besides cluttering up the file with dummy elements there is also the problem when your reference is somewhere at the end of a paragraph and therefore probably not on the same page than the start of the paragraph anymore. The backlink will navigate you back to the <div> and not to the place of the actual reference.
Another problem is that when having two or more references per paragraph you need two or more <div></div> pairs but in this case the device causes havoc again and does not work as expected. Although this solution DOES work in their iOS app.
The only hack to solve THIS problem is to put the two <div></div> pairs at the beginning of the paragraph in reversed order, first the pair for the second reference and then the one for the first reference.
But this gets ugly pretty soon so I refrained from figuring out how even more references per paragraph would turn out…
— — —