Question: fb2 in-page footnotes justified

[hius07]

https://github.com/poire-z, can you please help me to have fb2 in-page footnotes justified, same as popup footnote.
I've played with User style tweaks, cr3.ini, footnotewidget.lua with no success.

[poire-z]

A user style tweak with this should work:

body[name="notes"] section,
body[name="comments"] section {
   text-align: justify !important;
}

Does that work ?
If not, can you try to see by inspecting the HTML where a text-align: left comes from.

I added recently text-align: justify; to the "book style tweak" sample:

koreader/frontend/apps/reader/modules/readerstyletweak.lua

Lines 591 to 602 in 8a61e70

	local BOOK_TWEAK_SAMPLE_CSS = [[
	p.someTitleClassName { text-indent: 0; }
	DIV.advertisement { display: none !important; }
	.footnoteContainerClassName {
	font-size: 0.8rem !important;
	text-align: justify !important;
	margin: 0 !important;
	-cr-hint: footnote-inpage;
	}
	]]

Because I sometimes (but rarely) got them non-justified, and I figured it would not hurt there (a user can just erase that sample line).
Dunno if we should switch all in-page footnotes tweaks to text-align: justify.

[poire-z]

Even if it works, can you try to see where a text-align: left comes from. Obviously, it's not you who set it via another style tweak.

[hius07]

The user style tweak doesn't work.
I've checked cr3.ini, fb2.css, cr3.css, the book itself - no left-aligned instructions.
The text of the footnote is left-aligned both in the in-page footnote and in the end of the book.

[hius07]

I've applied the sample of Book-specific tweak - doesn't work.

[hius07]

I cannot trace the source of the text-align:left instruction, the html code shows just [body name="notes"], [section] and [p].

[poire-z]

Try this, forcing it on all descendants:

body[name="notes"] section *,
body[name="comments"] section * {
   text-align: justify !important;
}

It's only on this specific FB2 book (can you share it?), or does it happen with all FB2 books?

[hius07]

Doesn't work. All fb2 books.

[poire-z]

So, please share one (that you can share), so we can see if it's you only - and if I can reproduce I'll investigate.

Btw, on your first post, it seems fine on the 2nd screenshot (?) - or did I not undestand the issue?

[hius07]

The second screenshot shows popup footnote which is Okay.
Лондон - Мартин Иден.fb2.zip

[poire-z]

The second screenshot shows popup footnote

Oh, right :)

OK, I can reproduce it - and it does not happen with a koreader 2020.04.1-12 I had around.
So, probably a bug caused by some of my recent changes... :(
I'll look into it - you can stop fighting it with style tweaks.

[poire-z]

Caused by koreader/crengine@28ae22c and probably related to the specific display: run-in only used by FB2 footnotes

[hius07]

I've changed in fb2.css run-in to auto and got justified footnote, the text starting the next line of the footnote number. User style tweak works.

[poire-z]

Should be fixed with koreader/crengine#353.
(You'll find there an alternative way of handling FB2 footnotes with floats, to replace the similar stuff in fb2.css with - if you need a quick temporary fix :)

[hius07]

Thank you very much, I'll wait for the build to test.

[hius07]

Dunno if we should switch all in-page footnotes tweaks to text-align: justify.

Can in-page footnotes follow the alignment settings of the main text?

[poire-z]

For FB2, they did, and they will with the fix.
They are a <p> , so are affected by the Style tweaks > Text > Alignment > Left/justify most text.
And FB2 do not have class= I think, and aren't really styled by publishers (is this right ?)

With EPUBs, it's more wild, as they can be in a DIV, and some publisher can explicitely set them to text-align: left. But some people may like them like that. I just wondered how many people :)
It's quite rare - so I guess we can let them as-is, not overriding publishers and using our default of justify as a fallback.

[hius07]

Nice, in fb2 books by default we will have both main text and in-page footnotes justified (as per fb2.css setting for <p>).
Yes, fb2 books are not really styled by publishers, just marked up.

[hius07]

In-page footnotes are now perfectly justified, thanks a lot!

I'm not sure if it is worth your attention, anyway: the space between the number and the text in in-page footnotes is doubled comparing to popup footnotes.

[poire-z]

That is (and has been for a long time - it's original upstream code) explicitely done by adding 2 UNICODE_NO_BREAK_SPACE between the number and the text:
https://github.com/koreader/crengine/blob/59483446bc777b211cb23181bc8f6c60b94a1c1b/crengine/src/lvrend.cpp#L3175-L3184
and some checks to avoid having these spaces expanded or compressed by text justification:
https://github.com/koreader/crengine/blob/59483446bc777b211cb23181bc8f6c60b94a1c1b/crengine/src/lvtextfm.cpp#L3052-L3062

So, I guess someone prefered them that way, unless it's just some technical trick, not sure.
About that last bit, I added this as a comment in some current work on cleaning some stuff:

// For FB2 footnotes, renderFinalBlock() has added between the
// footnote number (set display: run-in) and the following text
// these 2 UNICODE_NO_BREAK_SPACE (flagged LTEXT_FLAG_PREFORMATTED).
// This condition and the following one might handle keeping their
// widths constant, or might handle leading real space in the
// footnote number or footnote text...
// But as the are LTEXT_FLAG_PREFORMATTED, they might not yet
// collapse.
// This might need some rethinking.

Btw, I dropped the idea of using float: left I mentionned above mainly because with it, I couldn't ensure a space between the number and text.

[poire-z]

the space between the number and the text in in-page footnotes is doubled comparing to popup footnotes

And which do you prefer ?

[hius07]

One space as in popup.

[hius07]

Good day,

This book shows no space after number in popup footnotes.
Besides, popup footnotes don't render the [emphasis] tag.
Голсуорси Джон - В петле.fb2.zip

This book has [stylesheet] section in the beginning (which is rare for fb2 books from Flibusta).

[poire-z]

Unlike most of the others FB2, this one have the footnotes part stuck to each other in the source:

<section id="n_6"><title><p>[6]</p></title><p><emphasis>¿¿¿¿¿¿¿¿¿ ¿¿¿¿¿¿</emphasis> (1836¿1914) ¿ ¿¿¿¿¿¿¿¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿¿ ¿¿¿¿¿¿¿, ¿¿¿¿¿¿¿¿¿ ¿¿¿¿¿¿ ¿¿¿¿ ¿ ¿¿¿¿ ¿¿¿¿¿-¿¿¿¿¿¿¿ ¿¿¿¿¿; ¿ 1895¿1903 . ¿¿¿¿¿¿¿ ¿¿¿¿ ¿¿¿¿¿¿¿¿ ¿¿¿¿¿¿¿.</p>
</section>

(pardon my latin1 not showing cyrillic :)
Most others have their source a bit formatted:

  <section id="n_10">
   <title>
    <p>10</p>
   </title>
   <p>¿¿¿¿¿¿¿¿ ¿ ¿¿. ¿¿¿¿¿¿. ¿¿¿¿¿.</p>
  </section>

So, when giving all that as-is to MuPDF, it gets some space between nodes and can show, once collapsed, at least a space between the number and the text - that it doesn't get in the first case.

I guess I could force adding one space after a node with display:run-in when crengine gives the HTML to our frontend code that will give it to MuPDF.

For the italic missing, FB2 has some non-standard HTML tags (like <emphasis> that MuPDF does not know about, so it displays them unformatted.
So, we'd need to add formatting for these non-standard tags in:

koreader/frontend/ui/widget/footnotewidget.lua

Lines 57 to 111 in f4dad2f

	-- Make default MuPDF styles (source/html/html-layout.c) a bit
	-- more similar to our epub.css ones, and more condensed to fit
	-- in a small bottom pannel
	local DEFAULT_CSS = [[
	body {
	margin: 0; /* MuPDF: margin: 1em */
	padding: 0;
	line-height: 1.3;
	text-align: justify;
	}
	/* We keep left and right margin the same so it also displays as expected in RTL */
	h1, h2, h3, h4, h5, h6 { margin: 0; } /* MuPDF: margin: XXem 0 , vary with level */
	blockquote { margin: 0 1em; } /* MuPDF: margin: 1em 40px */
	p { margin: 0; } /* MuPDF: margin: 1em 0 */
	ol { margin: 0; } /* MuPDF: margin: 1em 0; padding: 0 0 0 30pt */
	ul { margin: 0; } /* MuPDF: margin: 1em 0; padding: 0 0 0 30pt */
	dl { margin: 0; } /* MuPDF: margin: 1em 0 */
	dd { margin: 0 1em; } /* MuPDF: margin: 0 0 0 40px */
	pre { margin: 0.5em 0; } /* MuPDF: margin: 1em 0 */
	a { color: black; } /* MuPDF: color: #06C; */
	/* MuPDF has no support for text-decoration, so we can't underline links,
	* which is fine as we don't really need to provide link support */
	/* MuPDF draws the bullet for a standalone LI outside the margin.
	* Avoid it being displayed if the first node is a LI (in
	* Wikipedia EPUBs, each footnote is a LI */
	body > li { list-style-type: none; }
	/* MuPDF always aligns the last line to the left when text-align: justify,
	* which is wrong with RTL. So cancel justification on RTL elements: they
	* will be correctly aligned to the right */
	*[dir=rtl] { text-align: initial; }
	/* Remove any (possibly multiple) backlinks in Wikipedia EPUBs footnotes */
	.noprint { display: none; }
	/* Attempt to display FB2 footnotes as expected (as crengine does, putting
	* the footnote number on the same line as the first paragraph via its
	* support of "display: run-in" and a possibly added autoBoxing element) */
	body > section > autoBoxing > *,
	body > section > autoBoxing > title > *,
	body > section > title,
	body > section > title > p,
	body > section > p {
	display: inline;
	}
	body > section > autoBoxing + p,
	body > section > p + p {
	display: block;
	}
	body > section > autoBoxing > title,
	body > section > title {
	font-weight: bold;
	}
	]]

One would need to find out the ones that need to be formatted differently.
https://github.com/koreader/crengine/blob/master/cr3gui/data/fb2.css
https://github.com/koreader/crengine/blob/59483446bc777b211cb23181bc8f6c60b94a1c1b/crengine/include/fb2def.h#L137-L231
https://github.com/koreader/crengine/blob/master/fb2props/FictionBook2.2.xsd

Quick glance and I see emphasis and strikethrough might need it.
Mind having a more serious look ?

[hius07]

So, we'd need to add formatting for these non-standard tags in:

Will it be hardcoded that, say, [emphasis] is italic? Actually, it can be bold if one prefers to set it in fb2.css.

[poire-z]

It would be hardcoded (in footnotewidget.lua) in what we give to MuPDF for rendering popup footnotes. So, it should probably be the same as what we decided to be the default formatting for these tags in fb2.css.

[mergen3107]

Yeah, the same here. I haven’t seen a table in my fb2 books yet, but for the sake of a table being just a well-structured text, I’d go with decoration as simple as possible

[virxkane]

About buggins/coolreader@ccac737: I just restored the legacy table view style (which was in the old CoolReader). May be we must create separate fb2.css for e-ink devices, for example fb2-eink.css (and corresponding for epub, etc formats). I'm not sure, maybe the koreader is only for e-ink devices, so this is not a actual idea?

[poire-z]

I guess KOReader is mostly used on eInk devices, but we build it for Android (so, it can run on color phones and tablets), desktop linux and MacOS.
I don't think we need to bother with different eink/non-eink css. We don't have much color anyway in our epub.css (and I seem to be the only one complaining about grey refreshes/animations :/):

• table headers & captions (which are rare), which are ok having grey background I guess
• <HR>, which are small
• <A> text, which we set grey (nobody ever complained about it - but I hate it, so I set it to be black & bold in my own epub.css :)

For fb2.css, <A> are black, and table headers & captions have the same background colors as in epub.css
Anyway, I'll probably set table borders to be solid black as KOReader does not have many FB2 users possibly used to the old ridge rendering (and personally, I find "ridge" a bit too much 1990s and early HTML :)

[Frenzie]

I would agree that ridge isn't the best looking option. I generally prefer a simple solid or nothing.

[hius07]

I wonder waht are the reasons of appearing of extra empty line between the comment (endnote) 7 and footnote 1.
There are no empty lines in the text.

[poire-z]

It's probably not some empty line of text, but some margin - precisely some collapsed margin from previous content.
I sometimes get that with some EPUBs in-page footnotes too.

Each footnote is a slice of the document, the part that contain that SECTION:
body[name="notes"] section {-cr-hint: footnote-inpage;}
Normally, all SECTIONs are similar, and should have no margin.
Except the first one, that may get the top margin of its container, or even bottom margin from a previous node - which is probably what happens here: the first footnote gets the bottom margin of the title in bold.
(You can switch rendering mode to "legacy", that doesn't do margin collapsing, to see if you don't get them.)

This margin collapsing is per-specs (koreader/crengine#299).
In the implementation, we have to carry all margins met, to finally put it on the first element with content (so, the first footnote/SECTION here).
And this has this side effect with in-page footnotes, as we cut slices... we get the accumulated margin on the first footnote.

I have some patch (date Feb 13th) where I tried to fix that, that I did not follow up, probably because it caused some other issues:

--- a/crengine/src/lvrend.cpp
+++ b/crengine/src/lvrend.cpp
@@ -6561,8 +6561,15 @@ void renderBlockElementEnhanced( FlowState * flow, ldomNode * enode, int x, int

                 // Enter footnote body only after padding, to get rid of it
                 // and have lean in-page footnotes
-                if ( isFootNoteBody )
+                if ( isFootNoteBody ) {
+                    // If no padding were added, add an explicite 0-padding so that
+                    // any accumulated vertical margin is pushed here, and not
+                    // part of the footnote
+                    if (padding_top==0) {
+                        flow->addContentLine(0, RN_SPLIT_AFTER_AVOID, 0, true);
+                    }
                     flow->getPageContext()->enterFootNote( footnoteId );
+                }

                 // recurse all sub-blocks for blocks
                 int cnt = enode->getChildCount();

I can't get what you got with the FB2s I got from you.
Are you using our FB2 in-page footnotes style tweaks, or else ? They have margin: 0 !important, may be to counteract that?
If there's some specifc styling in that FB2, may be it can be solved by some additional styling in fb2.css, a bit like what I tried to do with the above patch. Something like:

body[name="comments"] > section:first-of-type,
body[name="notes"] > section:first-of-type {
  padding-top: 1px;
}
     /* or */
body[name="comments"] > title,
body[name="notes"] > title {
  margin-bottom: 0;
}

[hius07]

Thank you, I'll play with some settings. Here is the book if you are interested to try.
Golsuorsi_Forsayty-2.fb2.zip

[poire-z]

OK, I got it - and also with your other FB2 documents (somehow, I had all of them with render mode legacy :)
Anyway, unless I got some day a better solution to avoid that, it can be solved by tweaking our style tweaks (a bit ugly, but well...)

--- a/frontend/ui/data/css_tweaks.lua
+++ b/frontend/ui/data/css_tweaks.lua
@@ -654,37 +654,46 @@ Show FB2 footnote text at the bottom of pages that contain links to them.]]),
                     -- match in any other kind of document
                     css = [[
 body[name="notes"] section {
     -cr-only-if: fb2-document;
         -cr-hint: footnote-inpage;
         margin: 0 !important;
 }
 body[name="notes"] > section {
     -cr-only-if: fb2-document;
         font-size: 0.75rem;
+}
+body[name="notes"] > title {
+    margin-bottom: 0;      /* avoid title bottom margin from collapsing into */
+    padding-bottom: 0.5em; /* the first footnote by by substituting it with padding */
 }
                     ]],
                 },

[hius07]

Can we avoid showing footnote number as title (bold and increased) when it is in the title?

[hius07]

I mean, I can do it via User style tweaks, but shouldn't it be by default?

Well, the same is in poems (which are in italic by default).
Generally speaking, should (I believe yes) and can we protect the footnote number style?

[poire-z]

I can do it via User style tweaks

How did you do it, what tweak did you came up with?

but shouldn't it be by default?

For EPUB, I'd say it shouldn't (we respect cascading style sheets as the publisher might expect it).
For FB2, which is rarely styled, it's up to you readers (and how not ugly your style tweak can be :)

[hius07]

How did you do it, what tweak did you came up with?

a[type="note"] { font-weight: normal; } - worked for title.
Didn't try font-size.

[poire-z]

We already have:
a[type="note"] { vertical-align: super; font-size: 70%; text-decoration: none }
I guess you also want font-style: normal to remove italic.
70% is a % of the container font size. If you want a fixed size relative to the default font size, you can use font-size: 0.7rem (rem = root em = root font size). Dunno how that will play with the vertical alignment (if you reduce the a font size, it may get lower, I don't remember if it uses the container font size or the contained font size to compute the vertical shift. Might also try vertical-align: text-top or top if needed).

[hius07]

Am I right that by default a nested (cascading) element should always inherit style of its parent strictly without exclusions?

[poire-z]

Half right.
It inherits only inheritable styles. https://stackoverflow.com/questions/5612302/which-css-properties-are-inherited
font-weight, font-style are inheritable.
font-size is not (otherwise, with <span style="font-size: 70%"><span><span>test, you'll get the text with a font size of 0.7 x 0.7 x 0.7 x the initial font size).

edit: ok, font-size is in that list at that link. It means the computed font size is inherited, but not the specified property value.

[hius07]

OK, thank you for your comments.

[hius07]

Seems to have an issue showing poem/stanza in footnotes - no line breaks.
The same poem is included in the main text for testing. KOReader release 2020.08.
The book is attached.
1.fb2.zip

---

[poire-z]

Oh my... it worked in 2020.06 (before I rewrote display:run-in handling):

Will this FB2 footnotes/display:run-in nightmare ever stop... :/

[poire-z]

Well, the best I can do is to not ensure run-in number <stick them> first next paragraph when the "next paragraph" is actually something more complex than a simple paragraph (a simple paragraph is "rendered final" and contains only text, so we can do the trick - something more complex is "rendered block", and may contain other blocks that contain blocks that contains finally one or more more "final").
So that we don't break the blocks layout (it's technically not line breaks, each verse is actually a block laid out above each other).

Normally, instead of the <poem ~B> we have one or multiple <p ~F> and we just need the first one to be ~F to do the hack (the others can be ~B with no issue).

So, these (rare in the few FB2 books I have) would render as:

Currently, this one is also broken as the cite's P and text-author are stuck together:

(Didn't you already mentionned an issue with CITE in footnotes ? It rings a bell, but I can't find anything - maybe I'm mis-rembering...)

And your sample above would render as:

--- a/crengine/src/lvtinydom.cpp
+++ b/crengine/src/lvtinydom.cpp
@@ -6272,7 +6272,10 @@ void ldomNode::initNodeRendMethod()
                         }
                         i = j;
                     }
-                    else if ( i>0 ) {
+                    else if ( i>0 && node->getRendMethod() == erm_final ) {
+                        // (We skip the following if the current node is not erm_final, as
+                        // if it is erm_block, we would break the block layout by making
+                        // it all inline in an erm_final autoBoxing.)
                         // This node is not inline, but might be preceeded by a css_d_run_in node:
                         // https://css-tricks.com/run-in/
                         // https://developer.mozilla.org/en-US/docs/Web/CSS/display

(Given the margin that POEM and CITE have, it doesn't look that bad. If sticking the footnote number as a real display: run-in, we might have it contained with the first line of the POEM or CITE, so indented vs the other footnote numbers.)

[poire-z]

(Unrelated to previous comment.)

Footnote numbers may not be perfectly aligning (because digits have non-constant widths), but we could get something a bit nicer when the font has the tabular-nums OpenType feature, by adding:

--- a/cr3gui/data/fb2.css
+++ b/cr3gui/data/fb2.css
@@ -104,10 +104,11 @@ pre {
 body[name="notes"] section title,
 body[name="comments"] section title {
     display: run-in;   /* technical trick to have the footnote number inline with the followup text */
     font-weight: bold;
     font-size: 100%; /* counteract default of 110% with regular title */
+    font-variant: tabular-nums; /* get fixed-width digits for nicer text alignment */
     text-align: start; /* counteract default of center with regular title */
     page-break-before: auto; /* counteract default of always with regular title */
     page-break-inside: auto;
     page-break-after: auto;
 }

Before | After:
-

[hius07]

Given the margin that POEM and CITE have, it doesn't look that bad.

I agree, it may be accepted.

[poire-z]

Besides, text-author is not supported in the popup footnotes.

By "supported", you meant "styled", right ?
You'd need to add all the styles (for non-HTML FB2 elements) that may be found in footnotes in that bit so MuPDF can style them similarly as in the book:

koreader/frontend/ui/widget/footnotewidget.lua

Lines 93 to 96 in 671ea00

	/* Style some FB2 tags not known to MuPDF */
	emphasis { font-style: italic; }
	strikethrough { text-decoration: line-through; }
	underline { text-decoration: underline; }

Like for your poem above:

--- a/frontend/ui/widget/footnotewidget.lua
+++ b/frontend/ui/widget/footnotewidget.lua
@@ -94,6 +94,8 @@ body > li { list-style-type: none; }
 emphasis { font-style: italic; }
 strikethrough { text-decoration: line-through; }
 underline { text-decoration: underline; }
+text-author { font-weight: bold; font-style: italic; margin-left: 5%}
+poem, stanza, v { display:block; }

 /* Attempt to display FB2 footnotes as expected (as crengine does, putting
  * the footnote number on the same line as the first paragraph via its

I let you compile them if you want me to add them here.

[hius07]

Got it, thanks.