Require orthogonal designspaces for VFs
Opened this issue · 2 comments
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
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