That’s all great but the infrastructure of line layout and variables were intended to be implemented together, not Separated by 25 years and artificial barriers of the technologies that grew in between. So it’s always interesting to see what’s going wrong just because of the past politics, and how little has changed in “round two.”
John’s points touch on an interesting set of issues related to but not of VUID and VOTF. Variable components are one issue. We’ve provided an example of that in Decovar. There are two sets of masters because of the disconnect we think there is between nested variable components and variable glyphs. I’m not sure John’s proposal to change the font format will solve that, but because it is common enough, and John isn’t, I just assume so. By common enough, I think a lot of people recognize the need to build glyphs from variable components, and by uncommon enough, Johns experience in this is great.
It’s importent to write though, that our Google Font projects were not focused back on these issues yet. Nor was our proposal scoped to allow any request for change to the font format. Just the fundamental axes we thought obviously need to be added. These were specified, in some cases, to make the need for format change, or at least further discussion, more obvious. The Overhanging obviousness we are heading to, is that there needs to be little, or better, no difference, between the font format and the design format. As that is something that could take years, we do what we can, now.
So, we agree that the assembly of glyphs from variation space is one issue. Having discovered for ourselves in Decovar, the variable component side of things, and more, we also stand by all of the proposal and I expect that later change to the format will make some of it much more clear. Ahead of that clarity, we think, demonstrate and progress on our need to go into variation space for parts, and for whole glyphs. So, I’m not sure why one thing there would be Important Enough to change the font format while the other thing there is Not Important Enough to register as an axis.
Peter:;“E.g., one could imagine a font that doesn't have an optical size axis, but does have contrast, x-height,....”
It’s been demonstrated. Those is are not registered axes though, so forget mixing, much less saving a user’s opsz. And without the selection mantra officially registered either, good luck with Ui intelligence. Most users also understand primary and secondary colors, and colors are easier to sample and compare than type, because they are not defined relatively by the artist or color company, like the current OT spec mostly ignores actual typographic parameters. In addition, color does not get bent out of shape by OS and apps making up their own laws to govern its appearance, or by their adoption of rendering that makes some colors easy, and other colors nearly impossible to use.
You are probably right though, all this has to be done, done Right, and not just for Latin colors. Good luck!