Require orthogonal designspaces for VFs

[m4rc1e]

I've seen several VF projects which have non-orthogonal designspaces e.g:

Master setup

Master Name	wdth	wght
Condensed Thin	75	30
Condensed Regular	75	50
Condensed Black	75	80
Thin	100	30
Regular	100	55
Black	100	80

In the above example, the "Condensed Regular" and "Regular" have differing wght values (50 vs 55). By having differing values, it means the avar won't be able to map the "Condensed Regular" and "Regular" masters to the 400 usWeightClass (we need this!) correctly since it cannot map axes based on the values of other axes. Such functionality may happen if the avar table is upgraded in the future

Another approach is to add masters but this can increase the file size drastically. Imo, it is better to just design families so they are orthogonal from the start. If avar v2 appears, we can drop this requirement.

By map, I mean mapping user coordinates to fvar coordinates

cc@vv-monsalve, @tphinney, @davelab6 thoughts?

[tphinney]

It’s not only a problem finding the instance that is the Regular, but that anything between those two weights in the design space is ... undefined. I have seen the effect of this in fonts, and it is weird and bad. At least in theory one could see different results from different engines. (I could provide examples at a later date—currently without power due to ice storm.) I can’t imagine why this is not considered a failure that causes the font to be rejected. Ought to be covered by Font Bakery, IMO.

…

On Mon, Feb 15, 2021 at 8:47 AM Marc Foley ***@***.***> wrote: I've seen several VF projects which have non-orthogonal designspaces e.g: *Master setup* Master Name wdth wght Condensed Thin 75 30 Condensed Regular 75 50 Condensed Black 75 80 Thin 100 30 Regular 100 55 Black 100 80 In the above example, the "Condensed Regular" and "Regular" have differing wght values (50 vs 55). By having differing values, it means the avar won't be able to map the "Condensed Regular" and "Regular" masters to the 400 usWeightClass (we need this!) correctly since it cannot map axes based on the values of other axes. Such functionality may happen if the avar table is upgraded in the future Another approach is to add masters. In the above example, we could add 2 more masters and end up with an orthogonal designspace but this will increase the file size drastically. Imo, it is better to just design families so they are orthogonal from the start. If avar v2 appears, we can drop this requirement. *By map, I mean mapping user coordinates to fvar coordinates* ***@***.***, @tphinney <https://github.com/tphinney>, @davelab6 <https://github.com/davelab6> thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABR6WKWZWNFDRY4SRO2RVNDS7FFZPANCNFSM4XU7XFWA> .

[vv-monsalve]

Another approach is to add masters but this can increase the file size drastically. Imo, it is better to just design families so they are orthogonal from the start.

After reading a couple of related Issues (in statmake and Encode Sans) this seems to be the best practice or at least required to having functional interpolations for VFs.

I think particularly in cases as the one mentioned in the statmake issue, where the wght values differ not only at the master level, but also among weight instances for different widths. e.g.

Instance setup

Instance Name	wdth	wght
Light	100	53
SemiCondensed Light	87	47
Condensed Light	75	44
UltraCondensed Light	50	41

I can’t imagine why this is not considered a failure that causes the font
to be rejected. Ought to be covered by Font Bakery, IMO.

Perhaps this could be included in Simon's initiative