Adjust EPUB footnotes with backlink before text #8672
Conversation
| @@ -557,13 +557,7 @@ footnoteSection refLocation startCounter notes = do | |||
| container $ do | |||
| nl | |||
| hrtag | |||
| -- Keep the previous output exactly the same if we don't | |||
| -- have multiple notes sections | |||
| if startCounter == 1 | |||
There was a problem hiding this comment.
I've assumed that this can be dropped as long as ordered lists are not used anymore, is it really the case?
There was a problem hiding this comment.
No, it can't be dropped. This plays a significant role when you use --reference-location=block (or section), which causes the footnotes to be printed at the end of each block (or section). In that case we need to make sure that the numbering continues appropriately in each new footnote section.
| , "<ol>" | ||
| , "<li id=\"fn1\"><p>Down here.<a href=\"#fnref1\" class=\"footnote-back\">↩︎</a></p></li>" | ||
| , "<li id=\"fn2\"><p>The second note.<a href=\"#fnref2\" class=\"footnote-back\">↩︎</a></p></li>" | ||
| , "</ol>" | ||
| , "" | ||
| , "<div id=\"fn1\"><p><a href=\"#fnref1\" class=\"footnote-back\">1.</a> Down here.</p></div>" | ||
| , "<div id=\"fn2\"><p><a href=\"#fnref2\" class=\"footnote-back\">2.</a> The second note.</p></div>" |
There was a problem hiding this comment.
I don't think I like this change. Using ordered lists gives us much better formatting (content of a note is aligned), and it will work well even if the note is, say, a code block.
|
Pandoc's current system complies with http://kb.daisy.org/publishing/docs/html/notes.html which says that, when endnotes are used (as with pandoc), the backlink should come at the end of the note. I gather this still causes a problem on Kindle? Can you explain what the problem is, exactly? I'm willing to consider a system that moves the backlink to the front, although that seems inferior from a reader's perspective. (After reading the note, you don't want to have to scroll to the beginning of the note to find the backlink.) Perhaps this could be configurable. Making the backlink the note number itself requires moving away from the use of |
|
Yes, but the guidelines recommend backlinks at the end for endnotes...like the ones we provide by default. (See the link above.) |
|
Anyway, I just wanted to confirm that the problem described in #4491 still affects Kindle software. (After all, they've now had 4 years to fix it...) |
It's also true the other way around: when you click on a note and figure out that you don't want to read it, you don't want to have to scroll to the end of the note to find the backlink ;-) I don't have an opinion about
I agree that What about an option that selects between endnote (default, current behavior) and footnote ( |
That's certainly possible. We could also make the "footnote" behavior the default when generating HTML for epub. (And maybe if we did that we wouldn't need to make it user-configurable -- though perhaps some people would enjoy having the footnote behavior for web pages too?) We'd still need to figure out a good way of constructing the footnote div and inserting the number (again, keeping in mind that it won't necessarily begin with paragraph text). I suppose the simplest thing would be to put the number in a paragraph by itself if the note begins with something other than paragraph text. |
I was thinking the same. Maybe for a first PR, not user-configurable, to keep it simple. And later if needed, an option could be added for that.
I agree. I don't think there's a lot to do, the code written by @Porges already builds the footnote div and putting the note in a separate paragraph isn't complicated. What still needs to be done I think, is adding a "behavior" option to the function which generates the footnote section, and calling it with "behavior = footnotes" from epub writer. Maybe also a bit of CSS to display it nicely. I can try, but I'm not familiar with Haskell so I don't promise anything. @Porges, do you have time to tackle this it? Otherwise I'll do it. |
|
The HTML writer has a state variable |
|
I'll have a go at this. |
Many EPUB readers are thrown off by pandoc's current footnote output. Both the ol and the fact that the footnote backlink is at the end of the note seem to pose problems. With this commit, we now create a list of aside (or div) elements, instead of an ordered list. Each element begins with a note number that is linked back to the note reference. (So, the backlink occurs at the beginning rather than the end.) References: - https://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf - http://kb.daisy.org/publishing/docs/html/notes.html See #8672, closes #5583. Thanks to @Porges and @lewer.
|
See new PR #8676 - please test if you can. |
Many EPUB readers are thrown off by pandoc's current footnote output. Both the ol and the fact that the footnote backlink is at the end of the note seem to pose problems. With this commit, we now create a list of aside (or div) elements, instead of an ordered list. Each element begins with a note number that is linked back to the note reference. (So, the backlink occurs at the beginning rather than the end.) References: - https://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf - http://kb.daisy.org/publishing/docs/html/notes.html See #8672, closes #5583. Thanks to @Porges and @lewer.
|
Now that I've merged the other PR, this one is obsolete. Thank you! |
Currently, pandoc footnotes leads to buggy display with kindle (see #4491)
This PR aims at fixing #5583.
I have taken @Porges code.
The PR makes pandoc's footnotes compliant with https://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf (see p. 34, Method 2)
I don't code in haskell, so please review carefully. In particular, the code introduces an empty line between the
hrtagand the first footnote, empty line that should not be there but that I don't know how to remove. Any help with this? Thanks.