The goal you describe, of avoiding dead, redundant or inconsistently-implemented axes, is a goal I share. As for process, my first step was to get the OT spec into a form better amenable to that. I need to work on the next step. In the meantime, getting some discussion of potential axes is helpful, I think: a process will need some group of interested and informed contributors.
I will rehash a part of our conversation in Berlin regarding the use of whatever the heck values a type developer needs to record, backwards.
You, “Oh, I just now got it!”
You said that aft ei said this:
Me, “...well, the CVT is pretty valuable, it covers many of the same values we are talking about here, and no one knows what’s what, explicitly, in that Truetype table?!”
I will add here, that I would love to make the per mille values explicit to a script, and a glyph of that script, and to a pair of index points, and bend the world to an absolute standard. Just kidding. But, I commented as much into my CVTs for a decade, but then, I eventually converted to the wisdom of Microsoft’s unofficial standardization of the CVT values to specific unit per em measures of pretty specific representative glyphs in the font. You can check the history and effectiveness of that with Mike.
No one who ever hinted for aliased rendering, doubted the wisdom, operability or usefulness of the CVT table, even in its original chaotic Apple form. And no one who ever standardized those CVT values, across all fonts, failed to appreciate the enhanced programmability such standardization enabled. Failing to have consistent CVTs when hinting a family would lead to unbridled hinting chaos, you can check that with Ross.
Hinting for Cleartype rendering ultimately dulled the usefulness of the CVT down to the alignments, but to think the same values and more, are not present in variable fonts, no one would do that. Variables need a bigger list, and fewer value systems. The values I listed for you in Berlin were typographic points, degrees of rotation, per mille, pancakes per em and seconds of time. And I meant every word of it, except by pancakes, I mean pixels. You can check that with me.
Meanwhile, the spec? I see five registered axes, and five value systems. I read your fear of too many axes that won’t be used, and am all for being against that completely. That could get ugly, which is why I responded to Peter’s request to document these After Berlin. While I was there though, I listened very carefully to you and others. So when I wrote this proposal, I added the two additional values systems, to mark Unicode and OT features on an axis. You can check that with your Berlin presentation.
The spec of the five axes is a done deal, I assume, and it doesn’t work with our proposal, as I explained, among other things. Now, I must respond to client requests and add width and weight axes that do work with our proposal, and they will be exactly as I described them in Berlin. You can check that when I’m finished.
I have no desire to discuss it further, thanks for your input, mine is complete,
Your desire for “set-width [to be] maintained no matter all the other settings” would need a more substantial change in the spec. It is fundamental to GX/OT that deltas from each axis are accumulated by addition — it is impossible, in general, with one axis to override the effect of deltas that arise from other axes. Am I correct in understanding that you want to override the effect of other deltas only on certain outline points, such as the advance width point?
As far as I understand this, it w should be possible. You need to add on set of 'uni-width' deltas for each of the other deltas. The possible confusion is that you can't do it with on set of deltas but on axis can have more than one delta per axis.
For uni-width, presumably you would also need to delta all the GPOS kern lookups values to zero to disable kerning when the uni-width variation is enabled?
Comments
You said that aft ei said this:
As far as I understand this, it w should be possible. You need to add on set of 'uni-width' deltas for each of the other deltas. The possible confusion is that you can't do it with on set of deltas but on axis can have more than one delta per axis.