Variations: Define named instances

[asaumierdemers]

No description provided.

[asaumierdemers]

@sberlow @davelab6
I added Thin, Light, Regular, Medium, Bold, Black.
What else? Should we do some widths and optical sizes named instances?

[dberlow]

All named instances need my approval thanks. What is the request for, and in which contract, and what's the schedule?

[asaumierdemers]

@dberlow I am just going through the current issues, which I thought were part of the current contract.

[dberlow]

...let's hold this though, until we've talked through the definition of the space, and the changes to the granularity of weight and width, and the jumps, over the size range. e.g. you added "Thin, Light, Regular, Medium, Bold, Black."... at what size(s)?... + every named instance must have names for the locations on every other axes in the design space. There is no "Light" anymore — the minimum a name can be is "14pointLightNormal" or something, for the named instances among the registered axes, and it gets longer from there with GRAD, & co. So, if this is in contract part 1, that we need to name a lot of these, and STAT all of this up, I'd be surprised, because the STAT table, and all of these instances artificially increase the size and UI interference potential of such a var. what we do want to define, most likely in .js, or pagebotics,(the format is not ready perhaps, is the map of the relative per mille value jumps over the optical size range, between universally named weights, and widths, as you began to do, and as I indicate we need to discuss in the first sentence above. Thanks.

[asaumierdemers]

Ok sure, I will remove this for now

[sberlow]

I believe the only issues that DB has approved for completion are on Basecamp.

[davelab6]

I will remove this for now

While 64e949c was removed...

...I want to keep this issue open for now, and probably would like something like it to be added back. When David says,

There is no "Light" anymore — the minimum a name can be is "14pointLightNormal" or something, for the named instances among the registered axes, and it gets longer from there with GRAD, & co.

I am not sure that this is true, because a basic principle of software administration is that defaults ought to be implicit. Convention over configuration, and all that.

So, the "Light" is reasonably the design space location where all axes are at their default values except for the registered weight axis, which is dialed to where the "Light" non-variable font would be created out of a instantiator program.

I think its reasonable to assume that any fonts API that today exposes the 9 weights possible in CSS2's font-weight property will continue to do so for any variable font that has a weight axis; that is, such an API will serve 9 non-variable fonts to non-variable-capable browsers, as if it wasn't a variable font at all but rather a pre-variable font family.

A stat table listing those 9 instances, using a similar scheme to the above, will be needed for that to work.

[davelab6]

Neither Amstelvar-Roman-VF.ttf nor Amstelvar-Italic-VF.ttf have defined named instances, and this is important, so re-opening.

[sberlow]

I will assign to @dberlow,
Who will be able to assign names once the space further along

[dberlow]

I have doubted the ease of variable fonts to “back up” into a user-friendly selection of named instances. I believe they will end up in a menu as worse user experience than any font family now available.

And I think the “variable world” has arrived, where all browsers support variable fonts.

While it may be “a basic principle of software administration [] that defaults ought to be implicit”, I don’t see the defaults are implicit to users looking at a font menu, are they? I mean, the default opsz is 14. If I understand correctly, how does the user looking at a menu of Amstelvar know that, unless the 81 widths and weights of all of the 136 opszs (between 8 and 144), is identified with an opsz value?

That written, how would you like us to proceed?

[davelab6]

Closing as related to Amstelvar Alpha, however, will open a new issue as this remains an important consideration