Axis Registry: slant axis

[davelab6]

https://github.com/google/fonts/blob/4bd3c05add902033e8d9e7f0c6258bf67e9a4814/axisregistry/slant.textproto has only a fallback for 0, but @tphinney points out that a users of a family with a slnt would benefit from named style access to at least one slanted style. This will vary per family.

[RosaWagner]

Just to follow up on the conversation of this issue : https://github.com/googlefonts/gftools/issues/295 so axis registry stuff are gathered in that repo.

To resume:

• eng team confirmed in a share doc that the slant axis would be handled as any non-weight/ital axes (in the Google Fonts Universe). So like the width axis for example.

From that we can advise to NOT treat slant axis as an ital axis, but as a complete "Roman" font with an additional axis like width or whatever (ie. no italic style linking). It means that Slant fallbacks would go in the family name side of the file. Only upright styles in the FVAR table. It means we would have a case like : FontName RightLeaning Regular. It means that VF with slant axis wouldn't have any "Italic" counter-part family.

If possible, fallbacks could be:

• RigthLeaning = max(slnt) (negative value as per OTF spec)
• Upright = 0 (elided)
• LeftLeaning = min(slnt) (positive value as per OTF spec)

IF presence of "italic/cursive" alternates:

• Italic would be treated as usual (with a linked style for every roman styles from RightLeaning to LeftLeaning)
• Italic variable file would be separated from Roman
• This means no necessity of use of STAT format 4

IF you really want to have your slanted font as the "italic" of your upright styles, slant is therefore treated as usual italic:

• 2 separated VF (Roman/Italic), with proper style linking and nameID25
• presence ital axis (value 0/1) and not a slant axis
• no variation slider for slant.

[RosaWagner]

suggestion from call with Dave and Marc:

• we completely BAN the slant axis
• ital axis is only used to link 2 separate files (Roman/Italic)
• we create a custom axis: SLOP (slope), with integer values as fallback eg: 8deg

cc @m4rc1e @davelab6 @vv-monsalve @thundernixon @tphinney @eliheuer

[davelab6]

we completely BAN the slant axis

Not completely as we would not change Recursive and Inter which are already onboarded. But going forwards :)

ital axis is only used to link 2 separate files (Roman/Italic)

I believe we have no exceptions to that already, so that works well.

with integer values as fallback eg: 8deg

What about backslanted slant names, as we avoid the minus in style particles because it is used as the family-style separator?

[davelab6]

So, I agree that problems persist with the way ital and slnt are handled in major implementations (CSS, Mac Word, maybe others) - and ambiguity about this is hindering onboarding. To recap:

• Nyshadh did a nice write up of some of the issues around ital and slnt axes in 2019 for the internal GF eng team.

• Similarly, Stephen Nixon made an investigation for Recursive, which has both those axes: https://arrowtype.github.io/vf-slnt-test/slnt-ital-tests/index.html

• Per https://fonts.google.com/variablefonts?vfaxis=slnt we only have Recursive and Inter families with an slnt axis onboarded so far.

• After Inter was onboarded I asked the onboarding team to avoid onboarding any family with a ital or slnt axis provided by the upstream, and to only onboard VF families where the italics styles are provided in a separate file, and linked via STAT table.

• Today Gluten is merged into this repo's main branch and is on the internal sandbox, with only the wght axis, and without the slnt axis provided by Tyler (upstream). He is unhappy to see the family launched in prod in this state.

• Above, Rosalie has proposed avoiding the slnt axis and using a SLOP (Slope) axis instead, to avoid the problems that slnt causes.

To make a decision about if we are good to proceed with that, what else do we need to know?

[davelab6]

SLOP could be accurate to how linear interpolation works, becuase the slnt axis definition is lying :) https://twitter.com/axis_praxis/status/1083183293368029184

[RosaWagner]

To make a decision about if we are good to proceed with that, what else do we need to know?

• slant / ital axes
• Oblique / Italic style names
• italic angle parameter in OS/2

are all factors that are going to trigger (independently) some kind of style linking behaviour when clicking on the Italic button in desktop apps (in a very inconsistent way). Browsers and App should debug it obviously, for now I can't see how a font could have both axes without creating any conflict. Word Mac is extremely buggy in that regard.

[RosaWagner]

Until we take a decision, we can do as Marc was suggesting last time:

• only upright instances in FVAR table
• slant axis empty in STAT table

I link here all kind of tests that I made, you can jump directly to the conclusion part: https://gist.github.com/RosaWagner/f59cdc52e007913042f3f826a94d1f4f

[vv-monsalve]

• we create a custom axis: SLOP (slope), with integer values as fallback eg: 8deg

Sounds good. The advantage of deg values as fallbacks is it would allow negative and positive slope values while avoiding the leftLeaning rightLeaning discussion.

To make a decision about if we are good to proceed with that, what else do we need to know?

In a range that goes from -90 to +90, how many of them would need to be registered? So far, they still determine the number of static ttf instantiated. opsz, the other axis with numeric fallbacks needed to be reduced to 21 (still many and only covers positive ranges) based on some sort of industry standards. But in this case, there would be none.

What about backslanted slant names, as we avoid the minus in style particles because it is used as the family-style separator?

Just saw this. Would it be possible to use one ASCII separator (e.g backslash, FamilyName\8deg.ttf)?. An m prefix (FamilyNamem8deg.ttf)?

[vv-monsalve]

• slant / ital axes are all factors that are going to trigger (independently) some kind of style linking behaviour when clicking on the Italic button in desktop apps (in a very inconsistent way)

Even for SLOP axis? From your Slant Test Case, it seems a scenario of 2VF, Roman/Italic with a SLOP axis is working mostly well if there are no more degree instances added (Test 5).

On the flip side, would the Test 6 case prevent us from using the SLOP axis?

[RosaWagner]

Indeed Test 6 is showing that wether we have a slnt or a SLOP axis, instances can only be weight styles in Roman and Italic. Although, thanks to SLOP axis, we could have a full STAT table, cause we are sure it wouldn't be broken if browsers suddenly support slant axis. I think it's a loose-loose win-win meh-meh situation, and we just need to make a choice.

I wouldn't stop designers to have a slant axis as long as conditions mentioned are completed (no slnt values in stat, no slanted/italic instances in fvar) so we can upgrade them when the time comes. But would give the opportunity to create at least 'sloped' families with degrees suffix.

Instead of 0deg, 8deg, -8deg, we could have 90deg, 82deg, 98deg like the guidelines in Glyphs (the counter-clockwise thing is a bit counter-intuitive though for primates like me though)

[vv-monsalve]

Instead of 0deg, 8deg, -8deg, we could have 90deg, 82deg, 98deg like the guidelines in Glyphs (the counter-clockwise thing is a bit counter-intuitive though for primates like me though)

Agree on everything, including this one. It would be counter-intuitive for most users as it could be hard to picture what a possible 105deg would be. Hopefully, the \ could be an option, as it would be kind of graphic at the same time.

[RosaWagner]

Little update on my last testing with continuous slant/ital axis in Windows.

ITAL = 1

• [x] All instances from FVAR table get installed (including Italic instances)
• [x] MS Words doesn't display italic instances in font menu (cause should be accessible through italic button)
• [x] Style linking with Italic button works correctly

ITAL=-12

• [x] All instances from FVAR table get installed (including Italic instances). note: this is new
• [ ] MS Words doesn't display italic instances in font menu (cause should be accessible through italic button). note: italic instances are accessible through font menu though
• [ ] Style linking with Italic button works correctly. note: shows faux-italic instead

SLNT=-12 Same behaviour as ITAL=-12. Which kind of make sense.

The support is kinda similar for all cases in Mac.

So for conventional families with a one-direction leaning "slant" axis (which would associate a slanted value to an italic instance), I would recommend a continuous ital axis with [0-1] range (which is uncommon but allowed by OT Spec). We can slice them for now, and add support in gftool for making it easier (cf https://github.com/googlefonts/gftools/issues/627). I am confident that in a distant future we could re-assemble them to deliver a VF with continuous ital axis without breaking the Internet (which would not be the case with a slant axis). Although, slant axis is more in use on the web, and the proper way would be to have better support for it instead of searching for workarounds…