Font not applying on the header Title of book.

[Aslanyan99n]

I'm submitting a bug.
Font not applying on the header Title of book.
I am using swift-toolkit for supporting epub books.
When I setting font for book it not applying font for headers, it only work for text content.
I expected set correct font for each of text.

• Platform: iOS
• Browser / Rendering Engine: iOS WKWebView

[JayPanoz]

Hi,

We’re currently reworking ReadiumCSS into an unopinionated library so this feedback is very useful. Thank you.

Currently, headings are not targeted when changing the font in user settings:

https://github.com/readium/readium-css/blob/2e1bb29d02de1b2d36ec960eb90c2c4ac238b346/css/src/modules/user-settings-submodules/ReadiumCSS-fontFamily_pref.css#L13-L20

However, it’s handled differently for the “Accessible fonts”:

https://github.com/readium/readium-css/blob/2e1bb29d02de1b2d36ec960eb90c2c4ac238b346/css/src/modules/user-settings-submodules/ReadiumCSS-a11yFont_pref.css#L36-L42

Which smells like making an artificial distinction, since a user could use a non-accessibility-specific font for accessibility reasons.

There’s an accessibility normalisation flag available in that case, but it’s pretty global since it will also remove bolding, italicising, etc.

Originally, one goal was to find a balance between Reading System/apps’ overrides and authoring – in typography and book design fonts can carry a lot of meaning, and overriding may not be the ideal solution in some cases as meaning will be lost. So it’s not uncommon apps decide not to override the font for headings as a consequence.

That being said, there’s no way to guarantee we’re not losing meaning in body copy or divs, or lists, etc. And well, if you want to enjoy the original design, you can always switch back to publishers’ fonts.

So it’s a default we will have to discuss in the redesign process.

[Aslanyan99n]

Hi. Thank you for your valuable feedback. вт, 18 июн. 2024 г. в 18:38, Jiminy Panoz ***@***.***>:

…

Hi, We’re currently reworking ReadiumCSS into an unopinionated library so this feedback is very useful. Thank you. Currently, headings are not targeted when changing the font in user settings: https://github.com/readium/readium-css/blob/2e1bb29d02de1b2d36ec960eb90c2c4ac238b346/css/src/modules/user-settings-submodules/ReadiumCSS-fontFamily_pref.css#L13-L20 However, it’s handled differently for the “Accessible fonts”: https://github.com/readium/readium-css/blob/2e1bb29d02de1b2d36ec960eb90c2c4ac238b346/css/src/modules/user-settings-submodules/ReadiumCSS-a11yFont_pref.css#L36-L42 Which smells like making an artificial distinction, since a user could use a non-accessibility-specific font for accessibility reasons. There’s an accessibility normalisation flag available <https://readium.org/readium-css/docs/CSS12-user_prefs.html#accessibility-normalization> in that case, but it’s pretty global since it will also remove bolding, italicising, etc. Originally, one goal was to find a balance between Reading System/apps’ overrides and authoring – in typography and book design fonts can carry a lot of meaning, and overriding may not be the ideal solution in some cases as meaning will be lost. So it’s not uncommon apps decide not to override the font for headings as a consequence. That being said, there’s no way to guarantee we’re not losing meaning in body copy or divs, or lists, etc. And well, if you want to enjoy the original design, you can always switch back to publishers’ fonts. So it’s a default we will have to discuss in the redesign process. — Reply to this email directly, view it on GitHub <#147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQLEWF7GV3GOMIFXMXHK52LZIBA5HAVCNFSM6AAAAABJHVCR36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZWGI3DQNJWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>