Spec: let's mark the opsz default value "elidable" ?

[RosaWagner]

To resume:

• Fvar table in the VF only contains weight style instances. eg. FontName-Bold (wght=700, wdth=100, opsz=14).
• Static instances which have a different style from the weight style (eg. width), have it appended to the family name. eg. FontNameCondensed-BoldItalic (familyname = FontNameCondensed, stylename = Bold Italic)
• The "Normal" width is "elidable" in the STAT of the VF, and not mentioned in the static instance name. For eg. FontName-Bold (wght=700, wdth=100). That's good, fvar instances and static instances have consistent naming.

Proposal starts here:

We need the statics with an optical size axis named this way: FontNameXXpt-Weight.
----> As for the width axis, should we have the default optical size value elidable as well ? For eg. static name then would be FontName-Bold instead of FontName14pt-Bold. It would be more consistent with the VF fvar instances, but we would have to assume that the "normal" optical size is the "text size" (in a range of 10 to 16pt)… or this is up to the designer?

[davelab6]

This is correct; the value that is elided is implicitly the value that equals the default.

So eg in https://github.com/google/fonts/blob/master/axisregistry/grade.textproto we have

default_value: 0

and then later

fallback {
  name: "Normal"
  value: 0
}

Therefore this is elided.

It would be more consistent with the VF fvar instances, but we would have to assume that the "normal" optical size is the "text size" (in a range of 10 to 16pt)… or this is up to the designer?

We can't assume a library-wide default for opsz, or even a range of defaults. While not a libre font, DJR's Clavichord is a great illustration of this, as its optical size range is 76 to 332, which is carefully chosen to allow the stroke weight to remain at 0.5pt at all sizes.

That's why we have the axis default for opsz defined in each family METADATA file, which overrides the default_value: 14 in https://github.com/google/fonts/blob/master/axisregistry/optical_size.textproto#L8

So, in this case the elided value is the one defined in the METADATA file. Eg in https://github.com/google/fonts/blob/89ade4fa7b7663aec69d3202d2eefd928e78c467/ofl/ballet/METADATA.pb#L19-L23 we have

axes {
  tag: "opsz"
  min_value: 16.0
  default_value: 16.0
  max_value: 72.0
}

While drafting this, I noted that many of the families with an opsz axis (https://github.com/google/fonts/search?q=tag%3A+%22opsz%22) do not have their default value specified, and this needs to be corrected, and thus we need a fontbakery check to ensure the METADATA files that specify an opsz axis include a default value, and I think its good to do this even if it is 14; and this repo's Spec docs need to be updated with that requirement too.

Ultimately, static instances should elide default values, and the static fonts available in upstream repos should eventually match the static fonts instanced by the API. However, the exact way the instancing works is still being figured out, in google/fonts#2616, and in google/fonts#2702.

[RosaWagner]

I am a bit confused by this PR #82 and @garretrieger's comment:

• Opsz default axis registry value = 14
• Weight default axis registry value = 400

So if I have a font with opsz and wght axes, master origin is opsz=18, wght=300 (so these are the font's default values). METATDA.pb should be :

axes {
  tag: "wght"
  min_value: 300.0
  max_value: 700.0
}
axes {
  tag: "opsz"
  min_value: 10
  max_value: 144
}
registry_default_overrides {
  key: "opsz"
  value: 18
}

Edit: no need to override the default weigth value if the fvar instances cover a range containing regular 400.

[davelab6]

Having seens Marc's sheet today, I'm not sure if opsz should ever be elided, since it breaks the ordering.

[RosaWagner]

Yep, i think so too, user experience would be also clearer. But if we do, we have to accept inconsistency between fvar instances and static instancies.

[m4rc1e]

Slightly off topic.

@evanadams-zz raised an interesting point in yesterday's meeting. He thinks that using "pt" in the axis value name may make users believe that this style is only suitable for that particular pt size. Evan, please correct me if I'm wrong here.

[davelab6]

Interesting speculation, but I'm not sure what to do about it.

The onboarding team have prepared fonts based on the idea we will accept inconsistency between fvar instances and static instances, and never elide opsz

[RosaWagner]

Final answer is : opsz fallback should not be elided.

• To not break ordering in font menu
• To make obvious which optical size is the default one (if it is elided, it is not explicit anymore)
• Bonus: statics and VF won't enter in conflict (cause they will have inconsistent naming for default opsz)