Registered Axes Ranges

[davelab6]

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?

[dberlow]

This is a plan that says unstep the values, but not the type i.e. straighten out the sides of pyramid to the values of the 144 pt, and then step the style effects down through opsz within the 144 pt value system to 8 pt, where, on the sliders, effects are accurate relative to default of each size, stopping variation at the proper values of each size, via “caps” in the avar table.

I agree that this is a way of handling this, for the next stage, where I will rename all of the instances with values, no “min” or “max”, eliminate all the instances that can be in the avar instead, and rebuild all the documentation and specimens to the new values.

Otherwise I might as well stop everything that I’ve got for documentation now which I’d rather not do, preferring to use the current documentation as a springboard to show how an updated version is going to e]help. That starts with the next stage, like in two weeks I hope, going forward from a new value system and avar-rich designspace, and recomposing and relabeling what needs to be re documented.

[dberlow]

Picking up on DC request for Comparison of the Roboto-min.vf to Roboto Extremo.vf ; in particular how the values of Roboto wght and wdth match to Extremo at the same OS/2 wght/wdth locations.

The pdf below, and on the repo contains the comparison on a single page. Classic:Extremo wght-wdth compare broadside.pdf

The result, is that the weights of Extremo match, besides being adjusted some amount of weight at both the min and max at 14 pt, for that op-size's requirements.

The result also shows the width values, (75 Roboto vs 75 Extremo), do not match, because the wdth values of Extremo are from opsz max as requested Nov. 3.

Ideally there needs to be an avar2 table, but for now, the options I see:

to make the Roboto styles appear in Extremo in a Stat table, that's recognized in a user selected mode? or something. . .

Or,

revalue the width axes of the Extremo design space to the values in opsz14, making the wdth min 75 everywhere, (that'll then match Roboto again), keeping the wdth default at 100, and assigning a width max value according to the proportional values added to the width of the default, opsz14, wght400 will be around wdth130.

So then the extremo wdth axes would match Roboto from 75-100, and extend beyond 100 for the current extremo wdth max, which is wider than any existing Roboto Classic.