Ah, I see now that the readme mentions simulating grades, so using the "wght" flag is intentional, but I wonder if the param names should still be changed to min/maxWidthFontWeight, since some variable fonts (e.g. Amstelvar) actually do have a 'grade' variation axis?

The issue is there aren't many variable fonts that actually have grades, yet. Maybe the answer is to support both, or maybe add in actual grade support as it becomes more prevalent?

Since so few fonts include variable grades, maybe for the sake of keeping the script as small as possible it would make sense to only support variable weight for now?

Even if you hold off on supporting grades, though, I think it would make sense to change the parameter names from min/maxWidthVariableGrade to min/maxWidthFontWeight, so that if you ever end up wanting to support actual grades you don't have a naming collision issue, and so that what the script is actually doing is more transparent -- especially since the scales for weights and grades aren't necessarily comparable (e.g. looks like Amstelvar's grade range is 25–150).

(I would keep the reference in the readme about using weights to simulate grades, though, to keep the design intent behind supporting variable font-weights clear.)

(The script could continue to support the legacy min/maxVariableGrade params for the time being, of course, for backwards compatibility.)

Hey @tinymachine, I know you have this in #36 but should we pull it out and apply it on its own?

Also note that grade axes aren't consistent; eg Roboto Flex and San Francisco both have grade but with different axis details