Slant axis for script faces and more #37
Comments
|
Nothing states that the default instance must be slnt = 0; the axis description is only saying that "Regular" is slnt = 0. It's not clear to me what this means: "it remains the default along the slant axis until it snaps from the default to -7 and then slants according to spec from -7 to -14." Perhaps the current description for 'slnt' in the registry is too constrained in saying that 0 is required for "Regular". What is intended in that is assuming there is an upright that is truly vertical. Some questions to consider would be:
Regarding the Latin/Arabic issue: Yes, instances can have only one value for an axis; I can't imagine how it could be otherwise within the font. But let me ask: If you change the Latin slant from -9 to -14, how would you expect the Arabic slant to change? |
|
The overview says: “The variable font has a default instance, which corresponds to the position in the variation space with coordinates set to the default values for each axis specified in the 'fvar' table.”
Default means the style The user gets if they don’t have variations. Let’s hope that’s cleared up in the spec.
Btw, the non-intuitive Negative values for a css slant, has had to be corrected for just about everyone in Type design and typography, which means millions of people can soon be confused by that to. . . Millions. I think this axis just became relative and we need to return the parametric angle axis to our framework, with the intuitive values we originally proposed.
But at least slant is consistent with the other registered axis now, if a font has slant, bravo, but who knows what it is, Without looking.
…Sent from my iPad
On Jul 5, 2018, at 1:28 PM, Peter Constable ***@***.***> wrote:
Nothing states that the default instance must be slnt = 0; the axis description is only saying that "Regular" is slnt = 0.
ItThe variable font has a default instance, which corresponds to the position in the variation space with coordinates set to the default values for each axis specified in the 'fvar' table.'s not clear to me what this means: "it remains the default along the slant axis until it snaps from the default to -7 and then slants according to spec from -7 to -14."
Perhaps the current description for 'slnt' in the registry is too constrained in saying that 0 is required for "Regular". What is intended in that is assuming there is an upright that is truly vertical. Some questions to consider would be:
Would it be a problem if a variable font has no "Regular"? Does the default instance have to be "Regular"?
(The answer to the second have of that should be No.)
If the "Regular" font in a family isn't exactly vertical but, rather, leans to one side, should its slnt value reflect the actual angle, or should it be deemed as though it were 0, and other angles are set relative to that?
Regarding the Latin/Arabic issue: Yes, instances can have only one value for an axis; I can't imagine how it could be otherwise within the font. But let me ask: If you change the Latin slant from -9 to -14, how would you expect the Arabic slant to change?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I think that means the default values from the fvar table, not from the spec. Those do not have to be identical.
Maybe this could be called the "Fallback default" or something like this. For efficiently built variable fonts that do not have to work in a legacy environment, having the "Fallback default" at the axis default values may be a rare occurrence. Forcing the default instance to be backward compatible means adding a potentially large number of extra masters at the axis default positions. I would have to check how all the apps supporting VF handle this, but I'm pretty sure Chrome uses the first named instance as default, not the axis defaults instance. |
@m4rc1e encountered the same issue while working on Roboto-VF. |
|
This is also a problem demonstrated by and relevant to Inter, a popular libre font for UI. Test page: https://arrowtype.github.io/vf-slnt-test/ (It is also relevant to Recursive, my own typeface, which also has a Slant axis).
This is doubly shown by the fact that Chrome and Firefox render clockwise slants if positive I realize that the OpenType definition of Slant is based in traditional geometry, but clearly, users are more used to thinking in terms of clocks and CSS standards. Is there any possibility that OpenType's italicAngle field in the 'post' table could retain it's legacy standard, while the Slant axis is mapped to user expectations (i.e. positive angle = clockwise rotation)? Sure, that would confuse a few type designers and software developers, but if software devs are already implementing as if this were the case, wouldn't it save quite a lot of overall confusion to change the OT spec now, rather than fight this battle millions of times over? |
|
A new axis is badly needed here, I think - to fix both the inverted clock direction, and the fact that the value isn't really an angle at all -https://twitter.com/Lorp/status/1149961570371420160?s=19 - to which fixing will require avar2 or recognition of HOI as part of the spec |
|
avar2 is not needed to fix the angle difference – avar will do just fine: https://gist.github.com/jenskutilek/f328f2ca250e8b9ebad0fb398a5a64c1 |
We have group of issues related to the slant and italic axes.
One issue, is working on a Latin script face with only a slant axis and i’m wondering what to do with the spec in consideration of the fact there is no style in the family with a 0 degree slant.
The default for this script face is correctly designed at -9 degrees, and the axis is ranging from -7 to -14 degrees. We don’t want to backslant it to zero as that would be a waste of design and present a default style no one wants to publish.
So one option I can see is if the default is what it is, -9, not to spec for a slant axis, and then it remains the default along the slant axis until it snaps from the default to -7 and then slants according to spec from -7 to -14.
I question whether: if every slant axis is valued in degrees, and any two slant axis can be compared and normalized to each other by matching degrees, why does the default of a slant axis have to be 0?
People here and there are also discussing making some of an italic style come from slant, and some come from the ital axis, but I wonder if that’s even possible. It seems like slant really only was specified for obliquing a whole font, and ital was specified to substitute the whole font, though some glyphs in both cases may not be slanted for design reasons.
One other issue that has been raised repeatedly regarding this is that multiple scripts may involve slants at different angles in the same instance, e.g. with a Latin slanting -9 and Arabic slanting +9 degrees, but instances on the slant axis can only have one value.
Let us know if you please, thanks.
The text was updated successfully, but these errors were encountered: