Closed davelab6 closed 1 year ago
David Berlow recommends the following:
Another internal project, for iconography, needs both round and sharp, so the negative range of this axis can go sharp
Another internal project, for iconography, needs both round and sharp, so the negative range of this axis can go sharp
I think this is the whole idea around Terminal Shape axis, and the same reason why I've been advocating to register it to control terminal shapes from Pointy (we've discussed about avoiding sharp) to Rounded.
On an internal chat conversation
Dave said:
except for round which has a negative end for sharpness
yeah i am in a sense advocating duplication of sharp as its own axis, and as a negative end of round
The values of this axis should be:
min_value: -100
default_value: 0
max_value: 100
precision: 0
After today's meeting review of the expected behavior, this axis doesn't need the negative portion of the range.
So following up on that discussion plus the ones we've had around new axis registers, the suggestions for the axis would be:
tag: "ROND"
display_name: "Roundness"
min_value: 0
default_value: 0
max_value: 100
precision: 0
fallback {
name: "Default"
value: 0
}
fallback_only: false
description:
"Adjust variations from square shapes to increasingly rounded forms."
cc @chrissimpkins @MariannaPaszkowska
Thoughts about @dberlow's recommendations in https://github.com/googlefonts/axisregistry/issues/59#issuecomment-1219408886?
I think that maybe we include "Terminal" in the axis name so that it is clear how the axis should be used if this is intended only for terminals? And it we go with that approach, it might make sense to modify the axis tag to something like "TRRD" to capture terminal only semantics in the tag and make it distinct from a more general purpose / global rounding axis where "ROND" might be appropriate?
Adding Terminal
here would go against what we have discussed in the past in "Terminal Shape" about avoiding a term that refers to specific parts of the letters, limiting the possible use of the axis in other projects where the roundness can be applied to glyphs differently, for example in icon fonts. Among other reasons.
The use of the word "terminal" in the formerly proposed TSHP
was probably the key reason for preventing its inclusion in the first place.
Thanks Viv. OK, we'll revise #81. Let's try to land this axis in sandbox this week. Eng requested that we push an early build of this family to sandbox for testing.
That would also be useful for wavefont. I found out that "softness" axis can be close meaningful alternative though.
That would also be useful for wavefont. I found out that "softness" axis can be close meaningful alternative though.
Indeed, Wavefont was also on my mind.
ROND axis was added in #91
This is needed for an internal project that @chrissimpkins is leading, and is distinct from SOFT because that gives a "dipped in chocolate" treatment to each overall letterform, whereas the internal typeface only rounds terminals, using the quadratic bezier interpolated offcurve point technique.