tphinney
commented
4 years ago It is definitely not a good idea to put everything in fvar with this family: it is too many dang instances. Some apps and environments break in some way when confronted with 256+ instances. And menus become pretty unwieldy at a lot lower level than that.
I trimmed it further because in my testing I found that a traditional font menu becomes very unwieldy with over something like 100-150 instances. So I think that is a good soft limit for fvar. Initially, that is what I did.
That said, with more time and distance from being so deep in the project, and having more time and thought about the different environments, I find myself liking the idea of finding a middle way with fvar (meaning, even fewer than 100, but still a lot more than 9).
What would you say to an fvar with 9 weights, 3 widths, and italics (54 styles), plus a full set of all the other variants for just the regular weight? I think that comes to around 80, but I'd have to work it out.
I am on the fence about whether your proposal would spur STAT v4 table support, or just make the fonts less usable. Or perhaps a chunk of both! 😛
kateliev
It looks like the
fvarnamed instances are a complete set, based on the combinations possible with the STAT v4 named instances (which is expertly done btw)Based on a chat with @m4rc1e I propose that most of the named instances in the fvar table should only be in the STAT table as v4, and only the 100..900 weight styles (with all other axes at defaults) remain in fvar.
This should mean that legacy apps only see legacy styles, and if GF does this as policy, it should help spur support for STAT v4 tables.
Or, we should have all being duplicated in both STAT and fvar... What do you think? :)