Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bump crengine: normalized xpointers fix, FB2 footnotes tweaks #5904

Merged
merged 3 commits into from
Feb 27, 2020

Conversation

poire-z
Copy link
Contributor

@poire-z poire-z commented Feb 26, 2020

Will need a base bump for koreader/koreader-base#1055.

Includes koreader/crengine#329 :

  • toStringV2(): fix when target node is a boxing node
  • CSS font-family parsing: set usual default of sans-serif
  • FB2 footnotes: fix spurious newline ("display: run-in")
  • FB2 footnotes: disable hardcoded handling as in-page

cre.cpp: accepts classic FB2 footnotes in footnote popup detection

Make FB2 footnotes behaviour consistent with what we have for footnotes in EPUB:

  • FB2 footnotes are no more rendered in-page by default
  • In-page rendering can be enabled by the added Style tweak
  • FB2 footnotes can also show in footnote popup (with some added not-so-nice CSS so MuPDF can render them as crengine)

cre: setFontFace(): increase bias given to the main font
An attempt at solving this:
image
when selecting FreeSerif as the default font, and using "Ignore publisher font-family": any of our other fonts could be used for the italic text (actually, the first of our font that has an italic variant).
So we can get the nicer:
image


This change is Reviewable

Solve the issue when a font without bold and italic variants
is used as the default font (e.g. FreeSerif), and the style
tweak "Ignore publisher font-family" is used (which uses
a trick to cancel any font-family by requesting a font
named "NoSuchFont"):
When text is italic or bold, any of the registered fonts
which have a real italic or bold variant would win over our
default font, as the best substitute to NoSuchFont-Italic.
This gives our default font a bit more bias so it can
win in its scoring against the other fonts, and be rendered
as fake italic or fake bold - which will ensure consistent
font and line height.
(A bit hacky, but no alternative solution found.)
Includes:
- toStringV2(): fix when target node is a boxing node
- CSS font-family parsing: set usual default of sans-serif
- FB2 footnotes: fix spurious newline ("display: run-in")
- FB2 footnotes: disable hardcoded handling as in-page

cre.cpp: accepts classic FB2 footnotes in footnote popup
detection
- FB2 footnotes are no more rendered in-page by default
- In-page rendering can be enable by the added Style tweak
- FB2 footnotes can also show in footnote popup (with
  some added not-so-nice CSS so MuPDF can render them
  as crengine)
@poire-z poire-z merged commit a523259 into koreader:master Feb 27, 2020
@poire-z poire-z deleted the bump_crengine branch February 27, 2020 20:22
@@ -613,6 +613,22 @@ This is just an example, that will need to be adapted into a user style tweak.]]
},
{
title = _("In-page footnotes"),
{
id = "footnote-inpage_fb2";
title = _("In-page FB2 footnotes"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, did you see my comment on MR about being in favor of enabling these by default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I did. And you already mentionned that nearly a year ago.
See (again) my answer at #5015 (comment).
(Nothing much to add or remove from it one year later :| )

/* 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 > *,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bit late since it's already merged, but that body > part looks a bit unnecessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, not necessary to catch these FB2 footnotes.
But having them, as we know these FB2 footnotes are pure SECTION > (TITLE/P), and they'll be child of the HTMLBoxWidget added BODY, having them like this, we'll be sure to NOT have that applied on any (probably super rare) DIV > SECTION > TITLE/P that we could find in the inner content of some EPUB footnotes :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you can end up with div > section couldn't you also end up with body > section?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we could...
But in this case, I can't, here, distinguish if it comes from a FB2 footnote (and need these CSS tweaks) or if it comes from some EPUB footnote (and does need it).
But in the other case DIV > SECTION, I can.
So, just doing what I can :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants