Potential FontBakery check: overall visual sizing relative to common/fallback fonts

TL;DR: We should come up with a font sizing standard and suggest that new fonts follow it.

The problem

Fonts have very little standardization for their overall sizing. They generally fit within their UPM grid, but different fonts treat this differently. Even if two fonts are both 1000UPM (as checked by Google Fonts check 116), they may be scaled within that 1000 units in completely different ways. This results in three primary problems:

1. When using fonts to design and/or code a web layout, a designer wants to be able to try different options quickly and easily. However, the relative sizes of fonts can be very different, even for fonts that are stylistically similar. This means that in order to try different fonts, the CSS must be adjusted, and it can be difficult to isolate the two variables efficiently.
2. If a font has different sizing than its fallback fonts (e.g. font-family: Noto Serif, Times, serif) there will be a jump in size and possible reflow when the site loads for new visitors.
3. Accessibility guidelines WCAG 2.0 provide specifications for minimum color contrast on “text” and “large text.” Unfortunately, there isn’t much definition of what exact point sizes these are. Still, the fact that type sizes vary makes it more difficult for designers and developers to know that they are meeting the correct criteria for accessibility if they are using different fonts.

Expected behavior

Ideally, fonts would have only as much size difference as was needed to express their design ideas (e.g. unique relative vertical metrics, differences in width, contrast, shapes, etc) but fall within a standard which would make fonts more useful on the web, by solving the problems described above.

Proposal: a QA check for the relative sizing of new fonts, flagging outliers

A FontBakery QA could alert designers if the relative size of a given font is an outlier against common fonts. This might be something that designers could ignore if they were making creative display fonts, but something that could be a useful tool for those designing fonts intended for use in text and UI.

Diagrams of the issue

When different fonts are used for the same content, it is easy to see the size differences between them. Look, for example, at Noto Serif next to Tinos in the example below:

You can also see a sort of “bar chart” of comparitive line lengths, by setting type at a small size. This isn’t necessarily a huge problem, because letter width is a principle creative decision of font designs, so I wouldn’t want to evaluate font sizes based on line length. Still, you might expect “normal width” text fonts to have a bit more similarity than they do:

A common solution for mixing fonts is to match the x-height. Material Design provides a “Theme Editor” Sketch Plugin which, among other things, helps designers to try different fonts in place of the standard Roboto. When a new font is selected, it is swapped in place of Roboto, with its font size rescaled to match x-heights.

Using this tool, I’ve compared several popular fonts, to show the effect of matching fonts by x-height. The font sizes generated are one way to see the relative sizing compared to a “normal” font like Roboto. It works fairly well in the majority of cases, but sometimes, fonts still end up clearly visually bigger or smaller. In particular, a font with a relatively low x-Height (such as Adobe Caslon Pro or EB Garamond) will look massive next to common fallbacks like Times or Tinos.

A potential standard

As shown when x-height is matched, it is not necessarily a perfect solution due to other shifting dimensions like cap height, ascender height, and descender height, which also effect perceived size.

Potentially, something a little more flexible might be the average of x-height, cap height, and ascender height. This value could be considered a font’s “visual size” (I’m making this term up right now). I’m not 100% sure of this metric as a perfect one, because x-height letters do tend to make up the bulk of words in most text. Still, a quick test shows (in my opinion) that it brings the apparent sizing of two fonts closer than simply matching the x-height.

In a font with a relatively low x-height, matching its x-height to a more “normal” font makes it look too big, while matching averages does better:

In a font with a relatively tall x-height, matching its x-height to a more “normal” font makes it look too small, while matching averages does better:

If we really wanted to be clever about visual sizing, we could make a study of relative usage of letters in Latin script languages on popular websites, then base the visual size calculation off of that. Here’s some HTML + JS I used to make the above image, in case anyone wants to mess with the fonts or the calculations:

https://codesandbox.io/s/0qv6pl7qkw

You can check different Google Fonts by editing the list in

const gFontFamilies = ["Noto Serif", "EB Garamond"];

…or edit the variables just below that to pull in system / local fonts.

Suggested QA message for Font Bakery

If a font falls outside the bell curve of visual sizes for common fonts (say, OS fallback fonts or most popular fonts on Google Fonts), it could be flagged on FontBakery. For example, we might have a flag something like:

⚠️ WARN: Font’s visual size is >5% larger than common system fonts.

• The average of this font’s visual size (the average of the x-height, cap height, and ascender height) is 7.34% larger than common system fonts. This may make it harder to use in web layouts and more disruptive in font loading on web pages. Scale it down by 7.34%, while keeping the same UPM, to better match likely fallback fonts.

The tolerance we give (e.g. 5%) could be as loose or as specific as we want, but we would probably want some flexibility to allow for different design styles.

We could go so far as to automatically, programmatically scale sizes for fonts put into the library, but that would risk damaging outlines. Especially for fonts with fine details, this could break things. However, I believe there would be user benefit to having a relative size comparison be part of our QA process.

---

My thoughts around this are still forming, but hopefully this gives a starting point for a discussion, if others think this might be a useful QA check. If so, let me know, and I can try to write the FB test! But first, if you have thoughts around how we might define similar visual sizing, I want to zero-in on something flexible, accurate, fairly universal, and easy enough to explain.

[moyogo]

However, I also think that graphic / web designers shouldn’t have to completely readjust layouts in order to try out different fonts.

Fonts are designed for different optical sizes. Maybe it would be useful to have information or recommendation on how a font should be used. For example Font XYZ has a __ x-height and __ caps, use it for __ sizes, etc.

[thundernixon]

Is “WARN” too severe a response to oddly-scaled fonts? I’m basing that idea off the comment in checkrunner.py

WARN = Status('WARN', 4) # A check that results in WARN may indicate a problem, but also may be OK

…though I could also see “info” being an applicable response.

Are these status documented anywhere besides the Python code? I do have some confusion about what results need fixing, and which can be safely ignored.

That’s a good point about a font including taller scripts having a good reason for smaller-than-usual Latin metrics. Probably, it would be good to include that (and other example cases we can think of, such as creative display fonts) as a potential good reason for ignoring the check.