Add ExtraLight Instance

[vv-monsalve]

Hi @xotypeco,

Currently, the GF API is producing static fonts for each 100 stop in the weight axis, regardless if they are included in the original design, as in this case.
To ensure allow compatibility between VF and statics the inclusion of the ExtraLight stop has been required.

[xotypeco]

does anyone explain why they now require this? couldn't find it. do I need to do anything? does it actually create another typeface file that users will have to deal with?

(sorry for all the questions)

[vv-monsalve]

A warning note on this was included at some point in the Spec under Instantiated Static Fonts.

However, a user has asked to include all the stops also in the VFs as leaving them as they originally were (without including all the stops at each 100) is leading to an inconsistency between the served static ttf and the STAT table in the VF.

do I need to do anything?

Yes, including the new ExtraLight instance. But first, I would like to give a quick try to switch to our latest approach to build the fonts using our new gftools builder tool. If I see that is going to take longer than ideal I'll continue with the current PR for now.

But, the inclusion of the ExtraLight instance must be addressed eventually, if not now before upgrading to the final two axes VF.

I'll keep you posted.

[davelab6]

does anyone explain why they now require this?

At a high level, the fonts API is a system, and as such, the developers take a systematic approach to everything, as much as possible. Also, the API is used by millions of people, with lots of different software, and so the system tries to support them all as best as it can - especially with 'backward compatible' changes that do not "break" existing usage. Sometimes GF chooses to do this anyway, but we prefer not to.

So, the way weights worked before variable fonts is one to nine styles, 100 through 900. With variable fonts, the weights can be a fluid range, from 1 to 1,000. However, we are in a transition period where some software is VF capable and others are not, or, the old versions of the newly VF capable software remains in use. Therefore the API provides "fallbacks", static fonts derived from the variable font, for legacy software according to that principle of backwards compatibility. And according to the systematization principle, the system simply goes along the axis, and at each of the nine 100 values, if the axis covers that value, it derives a static font, and names it accordingly. Those static font files are then included in the download ZIP alongside the VF font file, and they are served as web fonts to web browsers not capable of using VFs.

If the difference between a weight value and +/- 200 weight units is good, but +/- 100 units is too subtle a difference, that suggests the values were made too far apart, and the range should ideally be shorter, so that each step of 100 is meaningful.

However, if a font family was already published with a 'thinly spread' range of weights, the backwards compatibility principle precludes changing it, since documents already using the min/max weight would stop working if they "went away".

Therefore, the system will start offering users the "pointless" intermediate weight, and they will come to expect that to be available in static and VF versions of the family.

I hope this explains.

[xotypeco]

this makes sense if the space between Thin and Light (specifically in the case of Big Shoulders, not in general) was ever meant to be one that interpolates. it is not. Thin is the skeleton (only), and the weight range goes from Light to Black. the distance is there on purpose.

so essentially what this does is create a false connection between Thin and Light weights because of a desire for nice numbers and completeness. it also reinforces a somewhat wrongheaded notion that just because you can make 100-900, you must.

[davelab6]

I am struggling to understand this, since, de facto, it does interpolate, in the sources.

I also struggle to see the current 100 weight of either Big Shoulders family as a skeleton; they are both quite thick, compared to other hairlines around....

I would expect that if the Thin is truly another family, it wouldn't interpolate in the sources, and it would have a separate family name (eg Almendra)

[xotypeco]

my point is just because someone expects to see a typeface extrapolate from 400-900 or 100-900 doesn't mean it was ever intended to be that way. it's just systems thinking for the sake of systems thinking.

[xotypeco]

ok never mind. go ahead and see if this can be done automatically and let me know when I need to add the instance so I won't intrude on anything Vivi's doing. it impacts Big Shoulders minimally.

my problem is with the entire concept. I see no reason to force weight stops into a collection just because someone somewhere likes nice numbers, especially for the sake of a backward-compatibility feature.

[davelab6]

The reason is that creating exceptions to the simple "loop over the range and spit out instances" code is (substantial) extra engineering work, which has a low ROI from the engineers' point of view, so they won't do it.

[xotypeco]

ok making things easy for the lazy or beleaguered, I understand. thanks.

[vv-monsalve]

I've done a PR with the new builder workflow for Big Shoulders main version. It includes a suggested ExtraLight weight that you can change to the value you consider best.
Thanks

[davelab6]

Thank you Vivi