Typeface Classifications with More Contrasting Strokes and Calculating Contrast

[njeleniauskas]

Hi Andrew!

Apologies if this has already been asked, but something has been on my mind about passing contrast with different typeface classifications.

My understanding is that testing/calculation is based on fonts that have generous, and relatively similar stroke contrasts — like Helvetica (neo-grotesque sans-serif), or Avenir (geometric sans-serif). And that for fonts with different x-heights, we should manually adjust to match these (Avenir would need to be increased by 1.1 to match Helvetica’s x-height).

Would this manual approach also be the approach for typefaces with more dynamic stroke contrasts? For example, higher contrast humanist (Optima) or especially didone (Bodoni) typefaces?

Finally, I’m curious if is it possible (or could it be) to integrate these variations into the calculation based on a chosen default, or something else?

[Myndex]

Hi @njeleniauskas, sorry for the delay in response, I didn't get a notification.

At the moment, the idea is to make a perceptual assessment, and the proceedure is described here:

APCA Readability Criterion: Reference Font Matching

As for better integration, yes that is a key goal, but the technology is still a work in progress. So for now, the idea is to make a visual match, and that visual match should be performed close to the sizes to be used.

One of the key goals here is to find ways to simplify and/or automate this process. Also, it is intended to create a set of pre-qualified offsets for various fonts.

[njeleniauskas]

Okay, great. That makes me wonder about the current challenge then. Say we want to optically adjust a didone font like Bodoni to be a reasonable size to read (thx for the reference btw). What would be an appropriate methodology to use?

My current thoughts are, if we want to ensure the "thin" axis of a character is sufficiently visible, what constitutes being sufficiently visible? Here a few reasonable options I can see (test: Bodoni at 400, reference: Helvetica at 400):

Case 1: Ensure the thin axis is at least 1/3 (maybe 2/5) of the stroke-width of the reference font.
Result: The ratio is a ~1.16x increase in the font-size (ref: 16, test: 18.5).

Case 2: Use the 100 weight of the test font for the thin-axis size.
Result: At 16px, the test font would be 1.37x, or 21.92px.

Case 3: Adjust the thin axis so that it matches the smallest readable size of the test font at the same weight.
Result: At 14.5px, the test font would need to be ~37.5px to match.

Other situations I considered create a much larger jump in font-size, and restrict usage considerably.

Also, when I only adjust optically, for an 18px reference I landed around 25px for the test font.

Part of the reason for this line of thinking is because stroke-contrast can be very high in some fonts. So I wasn’t sure what the best approach would be with fonts like Freight, where optical adjustments might be harder to assess (or where more guidance may be prudent).

[Myndex]

When we are talking about font with contrasting stroke thicknesses, things get a bit more complicated. Typically, the minor stroke is not per se needed (in a well designed font) for understanding. But this is very much a YMMV thing.

IMO the real solution is user personalization. Also, this is mainly "critical" at body text sizes.

For instance, some levels of the guidelines we are developing are only looking for matching the reference font for critical text like body text. It is much less of an issue for large headlines.

[sbustelo]

Hi @Myndex, @njeleniauskas. I’ve been running some experiments on this.

The "Thin Stroke Energy" criterion ( https://icograma.com/fontsizer.php#test-stroke ) calculates the font size needed to keep hairline strokes above a physical pixel floor, preventing anti-aliasing from diluting them into faint grays. While text may still be readable below this threshold, the typography loses its visual identity, so it makes no sense for a designer to go below that point.

The test includes a slider to adjust this pixel threshold. At 0.50px, Bodoni hits the ~25px ballpark mentioned by @njeleniauskas, matching classical typographic standards.

Since the engine is JavaScript, the source is fully open. I’d love your feedback, and you're welcome to adapt the algorithm for future APCA automation.