Paragraphs and headings not affected by font-size

[danielweck]

Issue originally reported by @jonaslil : https://github.com/edrlab/thorium-reader/issues/1550

Summary

All p elements are displayed with the same font size, regardless of publisher css.

Problem

Lack of variation in font size distorts the layout of title pages and other special text elements. Endnotes, bibliographies, figcaptions containing p:s, which are usually styled smaller, are rendered with body text size (= 1 em).

Variations in font size are a basic typographic means to communicate text structure and hierarchy.

Tested with v1.7.2 on Windows.

Example

Title page in Thorium

Main title much too small, publisher info much too large:

Title page in ADE

Sample book

Download book here

Code

HTML

    <section epub:type="titlepage" class="titlepage">
        <p class="book-author">Guss Mattsson</p>
        <p class="book-title">En tur om hörnet</p>
        <p class="book-subtitle">Bref till Dagens Press af G.&#8239;M.</p>
        <p class="editors">Utg. Clas Zilliacus</p>
        <p class="publisher">Svenska litteratursällskapet i Finland <br />Helsingfors 2021</p>
    </section>

CSS

p.book-author { font-size: 1.4em; font-style: italic; line-height: 1; margin-top: 2em; text-indent: 0; } p.book-title { font-family: "Source Serif Subhead", serif; text-transform: uppercase; font-size: 2.2em; letter-spacing: 0.025em; font-weight: bold; line-height: 1; margin-top: 1.5em; text-indent: 0; } p.book-author + p.book-title { margin-top: 1.5rem; } p.book-subtitle { font-size: 1.4em; line-height: 1.3; margin-top: 1.2rem; text-indent: 0; } p.editors { font-size: 1.25em; line-height: 1.3; margin-top: 3rem; font-style: italic; text-indent: 0; } p.publisher { font-size: 0.9em; line-height: 1.4; margin-top: 4rem; text-indent: 0; font-variant: small-caps; letter-spacing: 0.08em; page-break-before: avoid; }

---

Issue originally reported by @apgrover : https://github.com/edrlab/thorium-reader/issues/1508

Summary

Setting font-size on h1-h6 tags does not render a visual change. Default h1-h6 font sizes appear instead.

Scope

Observed in Thorium for PC/Mac v1.6.0

Expected

Setting font-size: 2.5em on h1-h6 will set each element to the same font size.

Observed

font-size: 2.5em is ignored on h1-h6 and default font size appears instead.

Code Example

HTML

            <h1 class="gx">A</h1>
            <h2 class="gx">A</h2>
            <h3 class="gx">A</h3>
            <h4 class="gx">A</h4>
            <h5 class="gx">A</h5>
            <h6 class="gx">A</h6>

CSS

.gx {
    font-size: 2.5em;
}

Sample file available upon request.

[danielweck]

I believe the culprit is: https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/modules/ReadiumCSS-fs_normalize.css#L18-L24

...and: https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/ReadiumCSS-default.css#L96-L135

@JayPanoz if you have time, do you know a workaround for this aggressive normalization of font size via REM units?

[danielweck]

[JayPanoz]

@danielweck I don’t have any workaround except not using this “fs-normalize” and switch to a native API for the font-size setting.

Remember this normalize exists because of EPUBs using absolute units e.g. px, pt, etc. and there is no way I can reduce the scope of this selector i.e. often every paragraph in the book has a class so if we used :not([class]) we would actually target zero paragraph and the font-size setting would not work at all.

EDITED BY @danielweck --- copied @JayPanoz 's comment here:

Yep, that’s the normalisation due to some EPUB authors using absolute values for font-size.

As usual the advice is to use a “native feature” to handle font-size setting if available/possible. Cf. https://github.com/readium/readium-css/issues/34

[danielweck]

I wonder how other reading systems deal with this? (Apple iBooks in particular)

In Readium "1" we used runtime-expensive script-driven DOM tree walk + style computation (effective pixel size) + scale factor ... so definitely not something we want to replicate with ReadiumCSS which is entirely declarative at this point.

[danielweck]

Apple Books on MacOS:

[jonaslil]

Thank you for considering this issue. There is another normalization issue which I think would be important to adress, the normalization of heading sizes: edrlab/thorium-reader#1508. Headings are such an important element in book layout and typography.

It is difficult to use Thorium for previewing epubs in a production process, or to recommend it to readers and colleagues, as long as it does not respect the book's stylesheet.

The epub specification agrees that author stylesheets need to be respected: https://www.w3.org/publishing/epub3/epub-contentdocs.html#sec-css-rs-overrides

[danielweck]

There is another normalization issue which I think would be important to adress, the normalization of heading sizes

Note that I have now merged issue https://github.com/edrlab/thorium-reader/issues/1508 here.

[danielweck]

Reminder of this informative discussion: https://github.com/readium/readium-css/issues/34

[danielweck]

Related / duplicate issue? https://github.com/readium/readium-css/issues/111

From Nancy Zhang. A sample was requested.

I’ve just noticed that text in Blockquote displays in smaller font size in Thorium although it is set up the same size as other text in the stylesheet.ccs file

but in Sigil, it is like this: the two portions of text in the same size:

and it looks like it is not adjustable in the Text panel; other text would change in size with the slider, but text in blockquote remains the same.

I was wondering what I have missed, why this portion of text shows smaller, and how I could make changes to the font size in blockquote in Thorium, if possible.

[danielweck]

Reported in Thorium by @dualpixel-digital :

Hi,

I have one more improvement/fix suggestion for the next release.

I have an alpha version of version 2, with debug option.

I would like to understand why Thorium doesn't respect the font-size value, in space in the h1-h6 tags?

Note the difference between the desired result (Readium) and the result of Thorium

Is there a best formatting practice in CSS to ensure text sizes are recognized?

[danielweck]

Another related issue from Thorium:

https://github.com/edrlab/thorium-reader/issues/1695

Reported by @spudthebud

===>

This is a fictitious user story to illustrate the point

User story I am 3rd year undergraduate with dyslexia. For my assignment, I am getting articles from peer-reviewed journals on a topic. I found an article that was published in EPUB. I opened it in Thorium and adjust the font in the settings. However, it does not apply consistently to the abstract or the headings of the article, as shown in this image. It also doesn't apply to fonts in tables.

This also applies to an book from a university publisher, as the next image shows:

[danielweck]

Merged from https://github.com/edrlab/thorium-reader/issues/1106

It seems I have a similar problem: I read books that contain code snippets in a monospace font. In order to still be able to read something, I have to greatly enlarge the font, but the code display remains very small in places. Also, the contrast in these areas is too weak. Changing the font and size in the settings does not change anything.

(Thorium-Reader on Windows 10, epub)

Even though I can read the "normal" text with the screen reader, it is better understanding to read the code examples myself.

Helpful would be therefore:

• a possibility to increase the font size of code examples.
• a better contrast for the areas

But otherwise this is a really nice program, thanks!

[danielweck]

Merged from https://github.com/edrlab/thorium-reader/issues/1106

Reading some programming books in EPUB format, I thought it would be cool to render code snippets, that are styled in CSS accordingly, in monospace font.

@danielweck, sorry, looks like I have instinctively switched the font because default one looks so Windows9x-ish and it's hard to read, I honestly don't remember when I did this 🙄 And default monospace is almost disappearing on 1920x1080 display. It wood be so cool if it could override fonts by category, e.g. 'Humanist' for sans serif, 'Monospace' for monospace etc.

[danielweck]

this sounds like something that is controlled by https://github.com/readium/readium-css right?

Indeed but we’re only applying font-family to a subset of HTML elements, which doesn’t contain markup elements for code, etc.

So it seems to me the user setting is applied to code because it’s using p class in this publication. If the markup in the book was using pre + code it shouldn’t have been overridden.

That said, it wouldn’t solve this rendering issue raised by @weiss-d

And default monospace is almost disappearing on 1920x1080 display. It wood be so cool if it could override fonts by category, e.g. 'Humanist' for sans serif, 'Monospace' for monospace etc.

That’s quite tricky with CSS only since emulating defaults (for sans-serif, serif, monospace, script, etc.) is not really a thing it was meant for. It’s more of an app concern as they have easier access to that (+ installed fonts) and then there’s the issue of force-overriding the authors’ stylesheets (cf. browsers).

But I can imagine Electron has something for that?

[man-we]

Now here's an actual user story:

I'm working for a large publisher, we're creating 1500-2000 EPUBs each year and have just moved from ADE to Thorium without knowing about this issue. We've got a well-tuned CSS in place for use in the majority our EPUBs, which is using rem values for regulating font size in the title page, and other places.

Has there really not been any progress on this issue in 18 months? It still persists because, rather than letting people who are erroneously using absolute units in an EPUBs CSS take the fall, the decision was made that font size must be aggressively normalized, even if relative units are used? Whereas font size is handled well enough by Apple Books, KPR and ADE? Without a checkbox to easily turn this normalization off?

Sorry, I'm honestly baffled.

@danielweck I don’t have any workaround except not using this “fs-normalize” and switch to a native API for the font-size setting.

Remember this normalize exists because of EPUBs using absolute units e.g. px, pt, etc. and there is no way I can reduce the scope of this selector i.e. often every paragraph in the book has a class so if we used :not([class]) we would actually target zero paragraph and the font-size setting would not work at all.

EDITED BY @danielweck --- copied @JayPanoz 's comment here:

Yep, that’s the normalisation due to some EPUB authors using absolute values for font-size.

As usual the advice is to use a “native feature” to handle font-size setting if available/possible. Cf. #34

[danielweck]

Hello @man-we , thank you for your feedback.

Readium CSS is an open-source project that could do with some love from developers / maintainers. Would your employer ("large publisher") be able to offer some help?

In Thorium we implemented a few tweaks / workarounds in order to address weird edge-cases in ReadiumCSS, but we always report problems upstream (here in this repository) just in case the issues we encounter specifically in Electron/Chromium also generally affect other projects (e.g. the Readium "mobile" iOS and Android toolkits).

Besides exploring issues related to proportional font scaling, I have been looking at ways to disable some ReadiumCSS features in order to come as close as possible to "leave me alone" (i.e. strict minimum alterations of publisher styles in order to preserve "essential" reading-system overrides, such as colour themes, word/line/paragraph spacing, etc.). However, whenever I turn off some of the "normalised" styling, I seem to come across weird edge-case issues with image dimensions / scaling (especially in paginated / CSS columns mode, not so much in vertical scrolling mode), or internationalisation problems (locales that have specific glyph rendering rules) ... the original developer of ReadiumCSS did a lot of research in order to come up with a sane baseline.

All that said, I completely agree that this particular font sizing issue needs to be bumped up the list of priorities. Let me have a look at Thorium/Electron/Chromium specifically. I need to revisit the workarounds I tried in past iterations.

[danielweck]

Related issue: https://github.com/readium/readium-css/issues/95

[danielweck]

report from @CLnordcompo

https://github.com/edrlab/thorium-reader/issues/2078

Here is the problem: Thorium poorly manages the size of titles and intertitles. It supports h1, h2, h3 tags and assigns a default size, depending on the size configured in user style sheets. This is not the case for other e-readers (ADE, iPad, etc.). Often implying that the same box title does not have the same rendering on the same work, the size depends on the level to which the box belongs. I am attaching a snippet of epub, with corresponding CSS, illustrating the case. Test.zip

Thanks in advance

[danielweck]

From https://github.com/edrlab/thorium-reader/issues/2073 By @riiski

Hi, I have noticed when changing reading fonts in Reader app on Windows that fonts does not change header font. Only "Duospace" font change headers (H1, h2, h3, ...). In this pic you can see that paragraph font is changed while header font is the same:

The code clearly shows that it is h1 header tag on xhtml file:

And css values on the h1 tag: