Italic via slnt?

[davelab6]

Is it possible to provide the Italic styles of a family from arbitrary slnt (and other) axis locations? I believe this is a shortcoming in the spec which recursive.design encountered. @arrowtype ?

[behdad]

Can you elaborate what this is about?

[arrowtype]

I'm a little unsure of @davelab6's specific request here.

In Recursive, there are "Italic" named instances that use slnt=-15. These are indicated in fvar and STAT tables.

Google Fonts and Workspace doesn't surface these italics, because ... they rely on the slant axis? I'm not quite sure of the technical reasons, but this issue might be related to that.

[davelab6]

@rosawagner please could you explain the Inter slnt axis problem

[davelab6]

In Recursive, there are "Italic" named instances that use slnt=-15. These are indicated in fvar and STAT tables.

Doesn't the Cursive axis also play a role?

[davelab6]

I also see that avar2 will allow a wide range of a slnt axis, and then a virtual ital axis that maps its 0..1 to a smaller range.

[Lorp]

Remember that this gives rise to unpleasant regions where both ital and slnt are non-zero. By having multiple <output> axis locations, some CRSV could be introduced as well as slnt. Despite the ugly regions, this is a good use of avar2 and will allow apps to offer the good old "I" button to get italics.

[arrowtype]

In Recursive, CRSV can be used to override the default rvrn substitutions which occur along the Slant axis. This allows an upright Italic or a slanted Roman.

[Lorp]

Sorry, my comment wasn’t accurate, since ital wouldn’t have any gvar data of its own. The (minor) issue is that slnt, being a visible axis, will still be available to the user to create instances whose external axis settings don’t look right.

[davelab6]

Visibility should mean simply a "See more" menu is not needed, but all axes should be accessible according to the current spec. I advocated in 2017 for 3 states of visibility, not 2, such that a 3rd "no UI" state was available for type designers to recommend.

What I and @dberow demonstrated on https://typetools.typenetwork.com in 2017 was that moving the 'user' axes (optical size, weight, grade, width) sliders will move the 'underlying' parametric axes.

Is that not how avar2 works?

[Lorp]

It’s how avar2 works internally, but the user never sees the adjusted axis values (just like avar1, the user only sees original input values for all axes). The feedback you get in samsa-avar2 (the changing axis values in the "grey" axes) is only visible because of the polyfill JS. The "blue" (input) axes in samsa-avar2 are never adjusted by the polyfill.

As a consequence, avar2 output axes that are not hidden may sometimes be confusing to users, who notice that (say) "XOPQ is still at 90 while the vertical stems have definitely got bigger".

The alternative – where the user sees the values updated by avar2 – is difficult to imagine, if the UI only has a single value display per axis.

[khaledhosny]

May be the font can have a hidden, private SLNT axis and both ital and slnt would avar2-derive from it (and potentially other axes).

[behdad]

May be the font can have a hidden, private SLNT axis and both ital and slnt would avar2-derive from it (and potentially other axes).

Yeah that sounds right to me.

[dberlow]

slnt has two issues vs the type world:

1. no one in design uses a positive values for a back-slant. All graphic design, type design, architecture and most other visual fields use positive values for clockwise, and negative for counter-clockwise. The spec is an embarrassment.
2. the default of all "regular" type styles is not 0 degrees of slant. Type's vast design spectrum contains and always has, back slanted, slightly slanted and severely slanted styles of type that are the default. The angle is not 0 and thus if a slant axis were desired in such a font family, its values would be wrong. The spec is an embarrassment.

ital is a poorly documented axis, from the first sentence, "Used to vary between non-italic and italic". ital is no more a variation than the switch from lining to old style figures, nor is it different from switching from the regular to the italic styles of an instance-based font family. It is in essence a class-based RVRN instruction and the entire rest of the section of MS documentation is junk.

"The Italic axis can be used as a variation axis within a variable font, though this is not expected to be common."

Please tell them for me, thanks.