feature request: pop-up footnotes

[juvilius]

It is possible to show a pop-up instead of jumping to the note when clicking on footnotes ¹ in the calibre reader and also on Kindles (Paperwhite & Oasis confirmed by me).
As far as I can tell this behaviour is due to the links containing two attributes like so:
<a class="noteref" epub:type="noteref" href=.....>1</a>

That is much more useful than jumping to, say, the end of the document.
So, in case it is simple to include those two attributes in footnotes, I would highly appreciate it.
They don't seem to bother other readers.

Footnotes

1. such as this ↩

[blandger]

Interesting... will see. I wonder if that will work on e-ink devices ?

[dieterplex]

With this changeset, dieterplex@333c7e25fb1a, Calibre ebook-viewer and iPhone Books works well. But it would jump to the position where the footnote lives in my Kindle Paperwhite when the epub book converted to mobi format by Calibre.

I have a reMarkable device but it didn't support well to footnotes natively.
Since KOReader could be install to reMarkable or other e-ink devices with Android apk. I try use KOReader to take screenshots for reference.

[juvilius]

Good timing - i've gotten my kindle Paperwhite back yesterday.

I have tested it with <a epub:type="noteref"...> and so on and it works.
For my kindle Paperwhite it is necessary to have the footnote itself be a <aside epub:type="footnote"...> with the respective id and I think it also helps to have another anchor inside it with the correct link back to the "noteref"-anchor.

The calibre reader doesn't care much as long as it sees an anchor with epub:type="noteref" in it.

[juvilius]

And as we're making changes: instead of putting the reference inside a <sup> it would suffice to change the style of the anchor to something like: .noteref { font-size: 0.75em; vertical-align: super; }.

[dieterplex]

This feature request seems viable, but randomly replacing strings provided by pulldown_cmark is not a good idea. There is no formal HTML post-processing neither in upstream mdBook nor in mdbook_epub could handle this kind of epub specific request. So we need a owned push_html to do that.

@juvilius Would you like to try this out from https://github.com/dieterplex/mdbook-epub/tree/footnote as you suggested?
BTW, aside seems not a valid tag could be used in epub2 format that mdbook-epub default to.

[juvilius]

@juvilius Would you like to try this out from https://github.com/dieterplex/mdbook-epub/tree/footnote as you suggested?

This works, amazing!

Thank you, @dieterplex !

I've tried to understand the many changes, but rust code eludes me.. would it be possible to merge with the upstream or is that too complex?

[blandger]

...randomly replacing strings provided by pulldown_cmark is not a good idea

Agree, I don't like that also.

... There is no formal HTML post-processing neither in upstream mdBook nor in mdbook_epub

I did some changes in mdbook code to make possible using improved version of 'link preprocessor'. My component version is little more sophisticated especially on 'code examples' for epub.

[blandger]

but randomly replacing strings provided by pulldown_cmark is not a good idea

Agree with you, I don't like it either.

There is no formal HTML post-processing neither in upstream mdBook nor in mdbook_epub...

I reused pre-processor from mdbook in separate branch. That is a little more sophisticated version suitable for epub format.
See at file = src/preprocess/links.rs
There is no 'post processors' for chapter at all, but it's possible to create it (in mdbook or mdbook-epub??). Actually there is no chance to contribute into mdbook, so mdbook-epub probably is single scenario.

[dieterplex]

Here it's going to convert mdbook -> epub, no just mdbook -> html. This crate is specialized in ePub and is responsible for preparing appropriate content, packaging valid format as the outcome. That's none of upstream's business and no need to bother processors to modify rendered html.
Like experiment changes, it just render ePub (rendering footnote with forked html writer) directly instead of html with original html writer from pulldown_cmark crate. I think that would be sufficient and is maintainable for epub specific spec changes in future.
I'm still not sure what changes should be done in PR that fit common use cases.
And note that this crate is default to create ePub 2 ebook currently.