google / google/fonts

Atkinson Hyperlegible Next: upstream archived, and a measured x-height/optical-size trade

Open
#10,820 1 comment 1 reaction 0 assignees View on GitHub
Dominant language
HTML
Stars
20.5k
Forks
2.9k
Avg merge
1d 21h
Merged PRs (30d)
95

Description

### Summary

`googlefonts/atkinson-hyperlegible-next` was archived on 2026-08-13, which leaves `ofl/atkinsonhyperlegiblenext` here without a live upstream to send changes to. This issue is not a bug report and not a font submission — it is a measurement result about the shipped binary, and one question at the end.

I maintain a reproducible machine-vision legibility benchmark ([protocol and data](https://github.com/JessieSalas/kept-legibility-index)): 24 typefaces rendered into 12 degradation conditions, read back by Apple's Vision recognizer with language correction off, scored on character accuracy, 8 shuffled repetitions per cell, per-repetition raw values published.

### What I measured

I built a variant of Atkinson Hyperlegible Next that changes three parameters and **redraws nothing**: the lowercase is uniformly scaled to 110% (raising x-height against untouched caps), +20 units of tracking throughout, and +52 units on `i`, `j`, `l`, `I`. Every outline is Atkinson's.

The result is not a win. It is a trade, and it goes both directions:

| condition | Atkinson Next | +10% x-height variant | Δ |
|---|---|---|---|
| **smallest size ≥90%** | **9 px** | **8 px** | **−1 px** |
| codes at a glance | 81.19 | **87.62** | **+6.43** |
| body 9 px | 95.78 | 96.72 | +0.94 |
| passthrough (noisy bg) | 96.15 | 97.60 | +1.45 |
| **crowded (tight-set)** | **99.32** | 97.16 | **−2.16** |
| codes 11 px | **87.00** | 85.89 | −1.11 |
| body 9 px blurred | **93.34** | 92.50 | −0.84 |
| grand mean | 95.98 | 96.42 | +0.44 |

**The grand means are a tie.** I have no published confidence interval for this specific pair, and for calibration my nearest measured contrast (+0.78 points) carries a 95% CI of [−0.07, +1.85] — so +0.44 is well inside noise and I am not claiming the variant is "better overall."

The two results I do think are real and worth someone's attention:

1. **The small-size threshold moves a full pixel**, 9 px → 8 px against a 90% criterion. That is the largest single-parameter threshold shift I have measured in this index.
2. **The crowding cell regresses**, 99.32 → 97.16. Atkinson as shipped is near-perfect at tight setting and the added tracking does not pay for itself there. If anything this is evidence *for* the current spacing.

### The caveat, stated plainly

**This instrument is not a proxy for the readers Atkinson Hyperlegible Next was designed for.** The brief is human low-vision reading, developed with the Braille Institute and a low-vision panel. My reader is an OCR engine. Machine and human confusion sets overlap without coinciding — humans are bound by perimetric complexity, crowding, and familiarity in ways a recognizer is not, and OCR-A is the field's standing reminder of what happens when a recogniser is allowed to drive letterform decisions.

So I make **no** claim about human reading speed, comprehension, accessibility, dyslexia, or low-vision performance, and nothing here should be read as one. The [claims ledger](https://github.com/JessieSalas/kept-legibility-index/blob/main/CLAIMS.md) scopes every sentence I publish.

Where I think it does have standing: low-vision readers routinely reach print through camera-based OCR — Seeing AI, OrCam, KNFB Reader, phone magnifiers. Atkinson's own purpose is print for low-vision audiences, and that print gets photographed by the same readers. Degradation in that pipeline sits inside the accessibility chain rather than competing with it.

### The question

Given the upstream is archived and this repo is now where the family actually lives: **is an optical-size treatment of interest for Atkinson Hyperlegible Next?**

Concretely — an `opsz` axis, or a companion small-text variant, where x-height rises and spacing opens as size drops. The measurement suggests the ingredients trade against each other rather than stack, so it would want a designer's judgement, not a script's. I am not proposing my variant for inclusion; it redraws nothing and I do not think a rescaled fork belongs in the library.

If the answer is "not a priority," that is a perfectly good answer and I will leave the data where it is for anyone who wants it. If it is useful, I am happy to run any specific comparison the maintainers or the original designers would want to see, including conditions I have not thought of.

*Disclosure: AI tooling (Claude) was used in the QA, measurement and packaging of the benchmark harness.*

Contributor guide

Open the contributing guide

Research direction

Start with the existing Atkinson Hyperlegible Next files under ofl/atkinsonhyperlegiblenext and review the linked benchmark protocol and data. The issue does not identify a file, test, or implementation path; it asks maintainers and designers to decide whether an opsz axis or companion small-text variant is appropriate. Done would require a scoped design direction rather than the submitted rescaled variant.

Written by the indexing model from the issue text.

Assessment

Domain
design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.