dberlow
commented
5 years ago I’ve created a sheet, first 6 columns, showing needed registered axes instances for safe xopq, yopq and xtra: A. Good instances are labeled as such, the parametric axis works as is. B. A value means it’s tailored to that C. Self cap, means the parametric axes is disabled by An instance with no parametric change D. Hand made or a glyph, means something must be edited.
https://docs.google.com/spreadsheets/d/1qdnmKKmFS9-1vxSeB_UK_SAMP-hyY8q2FjzJ6gDzYNQ
davelab6
Summary: we spoke of this in the spring; that if avar2 did not come along, we would have to make a choice between a. narrow some parametric axes with a few intermediates or b. Leave some broad parametric axes with many instances, (capping off and tailoring), to control the many double deltas in our far-flung designspace.
Looking at the current build’s axes of concern, (xtra yopq and xopq), I’ve been reviewing the parametric effects on this design space of Roboto extreme ascii and would like to make a decision this morning. If (a) above, There will be broad xtra, yopq and xopq axes, and around 60 additional instances to control them. And option (b) above, Narrower parametric axes will require 16 to 20 additional instances.
Process here is: to tailor each parametric axis for the optical size axis, and then for the extremes of weight and width for each optical size. The broader the parametric range, the more the change flings out beyond these basic instances and into the combinations of these axes, and that requires more control instances.
Are they ever going to do avar2?