In-page classic classname footnotes only display the first paragraph of the footnote

[emacsomancer]

• KOReader version: 2021.02
• Device: Kobo Aura H20 (1st) (but it's the same on Android as well)

Issue

In-page classic classname footnotes only display the first paragraph of the footnote.

Steps to reproduce

In style tweaks, choose "In-page classic classname footnotes" or "In-page classic classname footnotes (smaller)". Only the first paragraph of a footnote is displayed in-page. And there's no indication that the footnote is truncated. (I think ideally the entire footnote would be displayed, but another option could be some sort of indication that the footnote continues.)

[poire-z]

Only the first paragraph of a footnote is displayed in-page

Probably because each paragraph is inside a container marked with a "classic classname", making them 2 footnotes for the code.
We can't do what you want and automatically guess what is the publisher intent: all is driven by class names and containers.
But may be you can, by tweaking the class name selection via a user style tweak after inspecting the HTML code.
Some previous explanations that may help you understanding how this works and how one can find a solution for each particular book:
#5925 (comment)
#5707
#5812

[emacsomancer]

Thanks!

So, I attempted to create my own styletweak after inspecting the HTML code, but I don't seem to be interpreting it correctly, because even using my own styletweak (and no other tweaks) it's still only displaying the first paragraph inline. (I'll note that the pop-up footnotes correctly 'grab' all paragraphs associated with the footnote.)

Here's what the HTML code looks like for the footnote:

<p class="footnote"><a id="_doc_fragment_79_ch43fn4" class="calibre7"/><a
class="calibre7" href="#_doc_fragment_50_ich43fn4">4</a> Pellentesque dapibus
suscipit ligula.  Donec posuere augue in quam.  Etiam vel tortor sodales tellus
ultricies commodo.  Suspendisse potenti.  Aenean in sem ac leo mollis blandit.
Donec neque quam, dignissim in, mollis nec, sagittis eu, wisi.  Phasellus lacus.
Etiam laoreet quam sed arcu.  Phasellus at dui in ligula mollis ultricies.
Integer placerat tristique nisl.  Praesent augue.  Fusce commodo.  Vestibulum
convallis, lorem a tempus semper, dui dui euismod elit, vitae placerat urna
tortor vitae lacus.  Nullam libero mauris, consequat quis, varius et, dictum id,
arcu.  Mauris mollis tincidunt felis.  Aliquam feugiat tellus ut neque.  Nulla
facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et dictum
nunc justo sit amet elit.</p>
  <p class="footnotei">Etiam vel tortor sodales tellus ultricies commodo.  Donec
pretium posuere tellus.  Cras placerat accumsan nulla.  Nunc eleifend leo vitae
magna.  </p>
  <p class="footnotei">Phasellus lacus.  Aliquam erat volutpat.  Nulla posuere.
Nunc porta vulputate tellus.  Donec vitae dolor.  Nullam tempus.  Sed id ligula
quis est convallis tempor.  </p>

So, based on the model of the (smaller) classic classname footnotes (as these are the only ones which work at all on this book), I added in .footnotei, and then, when that didn't work, also .calibre7 for good measure:

.footnote, .footnotes, .footnotei, .fn,
.note, .note1, .note2, .note3, .calibre7, 
.ntb, .ntb-txt, .ntb-txt-j
{
    -cr-hint: footnote-inpage;
    margin: 0 !important;
    font-size: 0.8rem !important;
}

But using this, it still only displays the first paragraph of a footnote in the in-page footnotes.

[poire-z]

You need to look above, if there is a container for footnote + n x footnotei.
If you have

<div class=blah>
 <p class="footnote"><a id="_doc_fragment_79_ch43fn4" class="calibre7"/><a
class="calibre7" href="#_doc_fragment_50_ich43fn4">4</a> Pellentesque dapibus
suscipit ligula.</p>
  <p class="footnotei">Etiam vel tortor sodales tellus ultricies commodo.  Donec
pretium posuere tellus.  Cras placerat accumsan nulla.  Nunc eleifend leo vitae
magna.  </p>
  <p class="footnotei">Phasellus lacus.  Aliquam erat volutpat.  Nulla posuere.
Nunc porta vulputate tellus.  Donec vitae dolor.  Nullam tempus.  Sed id ligula
quis est convallis tempor.  </p>
</div>
<div class=blah>
 <p class="footnote"><a id="someId2">another footnote</p>
 <p class="footnotei">with another paragraph</p>
</div>

You can target div.blah {-cr-hint: footnote-inpage;}

If not, and it looks like:

 <p class="footnote"><a id="someId"></a>a footnote</p>
 <p class="footnotei">with another paragraph</p>
 <p class="footnote"><a id="someId2"></a>another footnote</p>
 <p class="footnotei">with another paragraph</p>

You're out of luck.

It may work for popup footnotes because the way they work, we can inspect more stuff - as the user has already expressed (by activating it) that it may be a footnote :)
In-page footnotes can't be that clever, they are build at rendering time - and there's no way to know if the next container is part of the same footnote or not.

[emacsomancer]

Nope, there's no container that includes both footnote and footnotei, unfortunately.

I suppose the only 'fix' for this would be to edit the .epub itself and create something like the labelled blah <div> which contains footnote and all subsequent footnotei (associated with that footnote).

[poire-z]

Another case of can't fix because the publisher did not help us:
https://www.mobileread.com/forums/showthread.php?t=341500

There are id= on both the P block container, and a inline A in it.
In the main page, the link targets the id of the A.

When parsing this, we see the P having -cr-hint: footnote-inpage (we can only set that on a block container, so putting it on the A inside won't help), so we associate this block to the ID of this P - and all these IDs are candidates for in-page footnotes.
But in the main page, looking at the A's href, we don't find it among the available in-page blocks, so no in-page footnotes.

If the P didn't have any id=, we would go look for the first inner id=, and we'll find it in the A - and it would work.
If the A's href= would target the P's id=, it would have worked too.
(Associating multiple ids to each in-page block candidates feels to costly.)

[poire-z]

@Frenzie https://www.mobileread.com/forums/showthread.php?p=4151712#post4151712

It will show up as a footnote if you move that ID attribute from the A element over to its parent P element

You don't even need to move the id from the A to the P, you just need to remove the id from the P.

If the P didn't have any id=, we would go look for the first inner id=, and we'll find it in the A - and it would work.

[poire-z]

https://www.mobileread.com/forums/showthread.php?p=4152304#post4152304

the first time I open it everything seems fine, the notes appear well. But if I go back to Folder and re-open it, from that point the book's format broken, text-align changes, table content gone, notes don't show, etc.

http://validator.idpf.org/ reports 1200 of these:
ERROR | text/part0020.html | 12 | 36 | Error while parsing file: attribute "mah0000182" not allowed here; expected attribute "class", "dir", "id", "lang", "style", "title" or "xml:lang"

The book has been (badly) updated to contain:

<p mah0000204="" class="footnote"><a href="part0010.html#mah0002634" id="mah0000204" class="pcalibre calibre12"><sup class="EBsup">3</sup></a>W cjilc lt h mlfwa iqduyot.</p>
<p mah0000206="" class="footnote"><a href="part0010.html#mah0002637" id="mah0000206" class="pcalibre calibre12"><sup class="EBsup">4</sup></a>Srpue.</p>
<p mah0000208="" class="footnote"><a href="part0010.html#mah0002638" id="mah0000208" class="pcalibre calibre12"><sup class="EBsup">5</sup></a>Msbqtvâ~@~Ye.</p>
<p mah0000210="" class="footnote"><a href="part0010.html#mah0002639" id="mah0000210" class="pcalibre calibre12"><sup class="EBsup">6</sup></a>Zqnsnchâ~@~Yp.</p>

and I think all goes bad because we reached our max number of attributes (1024).

We probably should show a warning when these limits are reached, and stop adding them to something that can't contain them.

[poire-z]

and I think all goes bad because we reached our max number of attributes (1024).

Well, our #define MAX_ELEMENT_TYPE_ID 1024 is not really a hard limit, but the initial size of these arrays. These array can and will grow when we need more.
But these was an issue when loading from cache when we have saved more than 1024. Should be fixed with koreader/crengine#454.

[Frenzie]

Neat!

…

On Tue, Sep 7, 2021 at 6:05 PM poire-z ***@***.***> wrote: and I think all goes bad because we reached our max number of attributes (1024). Well, our #define MAX_ELEMENT_TYPE_ID 1024 is not really a hard limit, but the initial size of these arrays. These array can and will grow when we need more. But these was an issue when loading from cache when we have saved more than 1024. Should be fixed with koreader/crengine#454 <koreader/crengine#454>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRQBIEHSTJY6QCXA7EUUDUAYZ6FANCNFSM4YDZYW6A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.