Paragraphs and headings not affected by font-size #112

danielweck · 2021-10-12T11:07:29Z

Issue originally reported by @jonaslil :
edrlab/thorium-reader#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 :
edrlab/thorium-reader#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.

The text was updated successfully, but these errors were encountered:

danielweck · 2021-10-12T11:12:41Z

I believe the culprit is:

readium-css/css/src/modules/ReadiumCSS-fs_normalize.css

Lines 18 to 24 in 5830114

    
           :root:--advanced-settings p, 
        
           :root:--advanced-settings li, 
        
           :root:--advanced-settings div, 
        
           :root:--advanced-settings pre, 
        
           :root:--advanced-settings dd { 
        
             font-size: 1rem !important; 
        
           }

...and:

readium-css/css/src/ReadiumCSS-default.css

Lines 96 to 135 in 5830114

    
           h1 { 
        
             margin-top: calc(var(--RS__flowSpacing) * 2); 
        
             margin-bottom: calc(var(--RS__flowSpacing) * 2); 
        
             /* The following is base font size * typescale power of 3 */ 
        
             font-size: calc(((1em * var(--RS__typeScale)) * var(--RS__typeScale)) * var(--RS__typeScale)); 
        
           } 
        
           h2 { 
        
             margin-top: calc(var(--RS__flowSpacing) * 2); 
        
             margin-bottom: var(--RS__flowSpacing); 
        
             /* The following is base font size * typescale power of 2 */ 
        
             font-size: calc((1em * var(--RS__typeScale)) * var(--RS__typeScale)); 
        
           } 
        
           h3 { 
        
             margin-top: var(--RS__flowSpacing); 
        
             margin-bottom: var(--RS__flowSpacing); 
        
             font-size: calc(1em * var(--RS__typeScale)); 
        
           } 
        
           h4 { 
        
             margin-top: var(--RS__flowSpacing); 
        
             margin-bottom: var(--RS__flowSpacing); 
        
             font-size: 1em; 
        
           } 
        
           h5 { 
        
             margin-top: var(--RS__flowSpacing); 
        
             margin-bottom: var(--RS__flowSpacing); 
        
             font-size: 1em; 
        
             font-variant: small-caps; 
        
           } 
        
           h6 { 
        
             margin-top: var(--RS__flowSpacing); 
        
             margin-bottom: 0; 
        
             font-size: 1em; 
        
             text-transform: lowercase; 
        
             font-variant: small-caps; 
        
           }

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

danielweck · 2021-10-12T11:15:20Z

JayPanoz · 2021-10-12T11:27:33Z

@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 · 2021-10-12T11:31:22Z

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 · 2021-10-12T11:32:46Z

Apple Books on MacOS:

jonaslil · 2021-10-12T14:55:49Z

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 · 2021-10-12T15:18:38Z

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 edrlab/thorium-reader#1508 here.

danielweck · 2021-10-12T15:20:52Z

Reminder of this informative discussion: #34

danielweck · 2021-10-15T21:13:59Z

Related / duplicate issue? #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 · 2022-05-03T10:43:09Z

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 · 2022-05-30T08:29:57Z

Another related issue from Thorium:

edrlab/thorium-reader#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 · 2022-08-26T18:15:24Z

Merged from edrlab/thorium-reader#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 · 2022-08-26T18:15:55Z

Merged from edrlab/thorium-reader#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 · 2022-08-26T18:16:08Z

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 · 2023-07-19T09:11:33Z

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 · 2023-07-19T11:25:05Z

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 · 2023-07-19T12:20:56Z

Related issue: #95

danielweck · 2024-03-18T09:56:40Z

report from @CLnordcompo

edrlab/thorium-reader#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 · 2024-04-24T12:04:40Z

From edrlab/thorium-reader#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:

Resolves #112, resolves #95, closes #34

danielweck mentioned this issue Oct 12, 2021

Paragraphs not affected by font-size edrlab/thorium-reader#1550

Closed

danielweck changed the title ~~Paragraphs not affected by font-size~~ Paragraphs and headings not affected by font-size Oct 12, 2021

danielweck mentioned this issue Oct 12, 2021

Heading tags not affected by font-size edrlab/thorium-reader#1508

Closed

danielweck mentioned this issue Oct 15, 2021

Adjusting font size for text in blockquote #111

Closed

danielweck mentioned this issue May 3, 2022

Thorium doesn't keep size in header tags (h1-h6) edrlab/thorium-reader#1678

Closed

danielweck mentioned this issue May 30, 2022

Font settings: Not applying to all parts of a peer-reviewed journal article edrlab/thorium-reader#1695

Closed

danielweck mentioned this issue Aug 26, 2022

EPUB: monospace rendering for code examples edrlab/thorium-reader#1106

Closed

danielweck mentioned this issue Mar 18, 2024

Not compliant with the style sheets used edrlab/thorium-reader#2078

Closed

danielweck mentioned this issue Apr 24, 2024

Thorium Reader change reading font does not work as expected. H1 does not change. edrlab/thorium-reader#2073

Closed

JayPanoz added a commit that referenced this issue Jul 2, 2024

Replace font-size user setting with zoom

a3d6293

Resolves #112, resolves #95, closes #34

JayPanoz closed this as completed in b703f76 Sep 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Paragraphs and headings not affected by font-size #112

Paragraphs and headings not affected by font-size #112

danielweck commented Oct 12, 2021 •

edited

Loading

danielweck commented Oct 12, 2021 •

edited

Loading

danielweck commented Oct 12, 2021

JayPanoz commented Oct 12, 2021 •

edited by danielweck

Loading

danielweck commented Oct 12, 2021 •

edited

Loading

danielweck commented Oct 12, 2021

jonaslil commented Oct 12, 2021

danielweck commented Oct 12, 2021

danielweck commented Oct 12, 2021

danielweck commented Oct 15, 2021 •

edited

Loading

danielweck commented May 3, 2022

danielweck commented May 30, 2022

danielweck commented Aug 26, 2022

danielweck commented Aug 26, 2022

danielweck commented Aug 26, 2022

man-we commented Jul 19, 2023

danielweck commented Jul 19, 2023

danielweck commented Jul 19, 2023

danielweck commented Mar 18, 2024 •

edited

Loading

danielweck commented Apr 24, 2024

Paragraphs and headings not affected by font-size #112

Paragraphs and headings not affected by font-size #112

Comments

danielweck commented Oct 12, 2021 • edited Loading

Summary

Problem

Example

Title page in Thorium

Title page in ADE

Sample book

Code

HTML

CSS

Summary

Scope

Expected

Observed

Code Example

HTML

CSS

danielweck commented Oct 12, 2021 • edited Loading

danielweck commented Oct 12, 2021

JayPanoz commented Oct 12, 2021 • edited by danielweck Loading

danielweck commented Oct 12, 2021 • edited Loading

danielweck commented Oct 12, 2021

jonaslil commented Oct 12, 2021

danielweck commented Oct 12, 2021

danielweck commented Oct 12, 2021

danielweck commented Oct 15, 2021 • edited Loading

danielweck commented May 3, 2022

danielweck commented May 30, 2022

danielweck commented Aug 26, 2022

danielweck commented Aug 26, 2022

danielweck commented Aug 26, 2022

man-we commented Jul 19, 2023

danielweck commented Jul 19, 2023

danielweck commented Jul 19, 2023

danielweck commented Mar 18, 2024 • edited Loading

danielweck commented Apr 24, 2024

danielweck commented Oct 12, 2021 •

edited

Loading

danielweck commented Oct 12, 2021 •

edited

Loading

JayPanoz commented Oct 12, 2021 •

edited by danielweck

Loading

danielweck commented Oct 12, 2021 •

edited

Loading

danielweck commented Oct 15, 2021 •

edited

Loading

danielweck commented Mar 18, 2024 •

edited

Loading