googlefonts / googlefonts/roboto-flex
Registered Axes Ranges
- Dominant language
- HTML
- Stars
- 525
- Forks
- 35
- PR merge metrics
- No merged PRs in 30d
Description
In a deck explaining the project, @dberlow made this comparison of the pre-var and Extremo '700' weight across optical sizes at pt size:

In addition to the Classic being grey and the Extremo being 100% black, I wasn't sure on first look if this was 700 or 900 or 1000; having confirmed it is 700, I must say that I do not think the 700 weight opsz 14 should shift that much.
To recap, this is shifting because the design space is an "up-side-down inverted pyramid", and we can choose where the "steps" are with the `avar` table and with additional intermediary masters, other than the min and max.
DB said the 'true values' of the registered axes in the pyramid are like this:
| opsz | wght | wdth
|---:|:---:|:---:|
| min 8 | 250-750 | 80-110
| def 14 | 200-800 | 75-120
| 36 | 100-900 | 50-140
| max 144 | 1-1000 | 25-150
Ideally in the future there needs to be an `avar2` table, so that these relationships can be better expressed (in fact, blending those 3 registered axes out of the underlying parametric ones :)
Yet, avar2 is some time away, and I also have some (perhaps misplaced) backwards compatibility concerns; the current 'classic' Roboto range is 100 to 900 (1, 3, 4, 5, 7, 9 hundred) so perhaps the axis range should not be less than that.
But, it can be more than that, without backwards compatibility concerns.
So, I think the right thing to do is to have the weight and width axes ranges be suitable for the opsz max.
The width axis already has the widest values in the design space; I believe we ought to do that to the wght too:
With a wght range of 1 to 1000, the 700 and 900 weights seen on https://fonts.google.com/specimen/Roboto at 14 opsz can not shift in Extremo; and the heavier designs seen in Extremo (in the image at the top) can exist at 901 to 1000 even at 14 opsz; and in larger sizes, they could shift more.
This should be possible with out additional intermediate masters, using only the `avar` table (as it exists today.)
DB pointed out the downside of this, that it is a "consistently over-valued space" anywhere but the opsz max of 144.
I believe the way to prevent it being 'messy' is to use the avar table to make the 'untrue values' become 'inert'; so no variation is visible when moving an axis slider in the inactive space. Like this:
| opsz | active wght | active wdth | inactive wght | inactive wdth |
|--------:|:-----------:|:-----------:|:--------------:|---------------:|
| min 8 | 250-750 | 80-110 | 1-249 751-1000 | 25-79, 111-150 |
| def 14 | 100-900 | 75-120 | 1-99 801-1000 | 25-74, 121-150 |
| 36 | 100-900 | 50-140 | 1-99 901-1000 | 25-49, 141-150 |
| max 144 | 1-1000 | 25-150 | | |
Thoughts?
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.