readium
CSS HTML5 patch causes some digits to descent from baseline
Original issue reported in Thorium's GitHub repository by @civodulab
https://github.com/edrlab/thorium-reader/issues/1936
Sorry for the multiple posts, the GitHub API is experiencing problems: https://www.githubstatus.com
So, the bug is that Readium CSS sets font-variant-numeric: oldstyle-nums proportional-nums; on the body element:
https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/modules/ReadiumCSS-html5patch.css#L59
Readium CSS forces old style numbers. This happens if they exists in the font set. One will consider it a bug while others will consider it's a feature.
It might be addressed thru documentation as a publisher can override it by setting aligned numbers with font-variant-numeric: normal;.
What @gautierchomel explained. Thatās more or less a ābest typography practiceā for body copy.
It should at least be disabled when applying one of the a11y typefaces or forcing the a11y normalisation, to confirm Gautierās snippet of CSS.
https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/modules/user-settings-submodules/ReadiumCSS-a11yFont_pref.css#L44-L51
Alright so this is a feature and not a bug, and actually also an attempt at normalising numerals for body composition since there is no guarantee fonts ship with oldstyle or lining by default, normal is up to the typefacesā designer ā e.g. Times New Roman comes with lining numerals while Georgia comes with oldstyle on MacOS, when nothing is applied.
So thereās not much to fix there, but maybe a feature request to make for a dedicated setting. Iām not sure it can be useful, especially as there is no guarantee both variants are included with every set of fonts, so users could also possibly find themselves with a setting that doesnāt visibly work while the issue is the font not having either lining or oldstyle variants.
Closing, but feel free to re-open another issue for that.