You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The latter is more recent and, with range [-1,1] seems better designed, so it would be good if the one hosted here can be either updated to match the other one, or clearly marked as deprecated. For those seeking to understand grad, it’s not clear which to use, as both pages come up in search results.
The text was updated successfully, but these errors were encountered:
The original proposal was based on parametric i.e. thousands/em measure of a common sample feature.
The -1,0,1 proposal was temporary, relying on the same range as the UI.
The update, what we’ve been asked to provide for a product test, -50, 0, 50, e.g. , is based on values relative to the default in os/2 wght unit in %.
I’ve (sort of), come to the conclusion that wherever there is an existing subjective value like with os/2 weight, people are gonna want to have values in those units, but when people wanna program according to the detailed sizes of things, including most vertical metrics, they of course need to use parametric values.
Currently two different
grad
axis proposals appear in search results:grad
proposal here in the Microsoft/OpenTypeDesignVariationAxisTags repograd
proposal in the TypeNetwork/Opentype-1.8-Axis-Proposal.The latter is more recent and, with range [-1,1] seems better designed, so it would be good if the one hosted here can be either updated to match the other one, or clearly marked as deprecated. For those seeking to understand
grad
, it’s not clear which to use, as both pages come up in search results.The text was updated successfully, but these errors were encountered: