On font weight (CSS, PANOSE) and accessibility #76
Replies: 1 comment
-
Hi @mahalisyarifuddin thank you for this. I've looked an Panose in the past, as have members of the web fonts group, and when looking across font styles, ie. serif, sans-serif, etc, found a lot of variation in Panose values. Another question is, the visual contrast of the given weight — and a further rub is that hinting and antialiasing effects at small sizes has a significant effect. Nevertheless, the equation you present is worth evaluating on a larger basis. Here's a sample page of fonts, the page is mainly discussing ways of aligning x-heights, or using the ex unit... but it will be clear that weight is an unsolved problem as EVERY sample font on this page is 400. https://www.myndex.com/WEB/xheightExample I/m on my way to a meeting but next day or two I'm going to pull up the Panose values for these fonts, and see how it plays out. Thank you for reading |
Beta Was this translation helpful? Give feedback.
-
Greetings!
Have been using APCA in my projects and always fascinated on discussions about this.
Your point about "it's not the color pair, it's the 'size'" is solid. And I have also seen the discussion about using the algorithm with "non-standard" fonts and ways to match it with the reference.
Which got me thinking: there should be an easier way to match the font weight with the reference one.
I researched CSS weight values of the reference font (Monotype's Helvetica Now Variable in this case) along with the two widely-used system fonts (Google's Roboto Flex and Apple's SF Pro Variable) and the relationship with PANOSE weight ratio, and came up with the equation of:
Y = 3625.4 / (X ^ 1.015)
where X is the CSS weight value and Y is the PANOSE weight ratio (cap height / E stem width).
Excel worksheet in case you want it.
On CSS and PANOSE weight.xlsx
On above discussion you said that we have to use our "typographer intuition" to match the weight. In the case of Raleway "400", it's looked alike Helvetica 300, and by using the equation,
(213 / 21) = 3625.4 / (X ^ 1.015)
X approx. 328
which is yeah, it should be "equivalent" to 300 weight for the APCA.
But in the case of this particular typeface called "Plus Jakarta Sans", I don't think I, or other people, can trust our "typographer intuition", as the "400" weight is just too thin than the reference but not quite "equivalent" to 300 weight, and by using the equation,
(224 / 24) = 3625.4 / (X ^ 1.015)
X approx. 356
It's borderline. We can round it into 400 though it's still not feel right.
Which also got me thinking: type design is arbitrary, it's always has been. Type designers always do whatever they want by assign certain weights by arbitrary nomenclatures and numerical values (they even did made extremely thick display typeface and assigned it into 400 weight and no one can blame them). But the fact that standard spec like CSS is also behaving the same (by choosing the arbitrary numbers like 400 should be regular and 700 should be bold) is just mind-boggling at best.
You will always have a bad time if you build some standard on top of arbitrary stuffs.
We should be using more quantitative solution.
PANOSE as a whole classification system is not perfect, but its weight ratio is quantitative and usable enough.
Imagine if there's some sort offont-panose-weight : book
orfont-weight-ratio : 5
.That's it.
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions