Allow axes to have option for "step" granularity controls (ON/OFF, A/B/C, etc)

[thundernixon]

Proposal: add "step" granularity control to variation axes

In many cases, smooth interpolation is desirable in a variable font. It clearly benefits users to have the ability to have precise, near-infinite control of the weight or width in a typeface, in many scenarios.

However, in some cases, I believe it would be beneficial to have "stepped" axes, in which the type designer could pre-assign the granularity of controls.

If this granularity were baked into fonts, that would then allow software/web makers to use stepped controls for variable font UI, such as the step input attribute in HTML. In fact, I imagine that the designspace control for such a granularity control might be something like the HTML counterpart.

<!-- HTML -->
<input type="range" min="5" max="10" step="0.01">

<!-- designspace axis, with proposed step -->
<axis tag="ital" name="Italic" minimum="0" maximum="1" default="0" step="1">
    <labelname xml:lang="en">Italic</labelname>
</axis>

Example use case : alternate characters

The ital axis of a font may control italic alternates in a font by swapping out characters such as a double-story 𝐚 for a single-story 𝒂. Of course, when shapes change this radically, there is not a useful way for the ital axis to provide smooth interpolation. Most of the time, this type of substitution will probably happen via a rule, which would look like this in a designspace:

    <rule name="italic">
      <conditionset>
        <condition name="Italic" minimum="0.5" maximum="1" />
      </conditionset>
      <sub name="a" with="a.italic" />
  </rule>

However, because there is no step attribute for variable axes, variable font UI is then confusing to users: while most axes show visible change over their control range (usual in the form of a slider), an axis control alternates will show no change for most of its movement.

This isn't necessarily just a two-value, "on/off" scenario, either. Fonts such as Roslindale Variable Italic show that it would be useful for a type designer to assign whatever granularity suits the

Example use case: axes which can smoothly interpolate, but shouldn't

It is widely agreed that one of the notable advantages of variable fonts is the ability to join multiple font styles into a single file, to improve compression and reduce download latency in webpages.

A step attribute could allow a font to have multiple compatible styles, even if they may not look particularly good in their interpolations. On the simple end of this would be fonts that transform from proportional to monospaced, or from serif to sans-serif. On the extreme end of this would be "super fonts" that folks like Underware have hypothesized, which could combine totally different fonts into a single variable font file by programmatically making different node structures compatible, disregarding the aesthetic beauty of intermediate results.

If we consider compression to be a benefit of variable fonts, both ends of this spectrum would be a valuable outcome for users and producers.

Users would have faster downloads from smaller overall font packages, and makers would be enabled to combine font styles that previously were blocked by unaesthetic intermediates.

How are axis steps different from named instances?

Of course, there is already a useful mechanism for pre-suggesting specific areas of a designspace. A font can include named instances so that users can easily access familiar, pre-determined styles like "Regular," "ExtraLight," "Condensed SemiBold Italic," and the like. Doesn't that fulfill the value of axis granularity controls?

Not quite.

The benefit of stepped axes would be that they would exist alongside smooth axes. This would allow variable font UIs to provide much more utility to end users. A font user could explore and play within a variable designspace without sticking to only named instances, but still have some guardrails against selecting intermediate values that aren't useful, and without wondering why some ranges give continuous change while others only respond within limited areas.

[thundernixon]

To give some visuals of ideas mentioned above, I'll use a font I am working on, recorded in use at Wakamai Fondue.

• The Weight range is smoothly interpolatable, of course. Useful.
• The Slant range is also smoothly interpolable. Useful, for the most part.
• The Italic range controls italic overrides. It basically controls off/auto/on for Italics. Off asserts roman forms through the Slant range, auto allows forms to be controlled by the Slant axis (as users probably expect by default), and on asserts italic forms across the Slant range. Currently, all the "action" in the Italic axis happens at -0.01, 0, and 0.01. However, I suspect that users will be confused why they can slide controls for the entire distance of floating points from –1 to +1, when results are only visible in the middle.

However, something that gets a little murkier is the middle ground of the Slant & Expression axes, at least large point sizes.

• For the most part, the font can slant without kinks. This has been a non-trivial effort, and I still expect to find accidental kinks on the sides if characters are ever printed at a truly large scale (say, 6-foot tall letters on sidewalk-level windows). In this case, it would be very useful to apply a step to limit slant of on or off, above a certain point size.
• At text sizes, the Expression axis looks quite good, all the way through. However, when enlarged, certain transformations don't look very good in the middle. For instance, look at the "outstroke" of the j, s, and i in the animation below, when the Expression axis is in its middle portion. These flatten out in an unsatisfying way, and lose their continous stroke thickness. To an extent, this sort of thing can be solved through clever design and bezier control. There are few kinks in intermediate styles, even with fairly intense shape changes and linear interpolation. However, this is a case in which some designers might wish to provide a stepped axis, to avoid middle styles altogether.

[behdad]

I feel like a more useful feature would be an axes flag that says only integral values on the axes are intended to be exposed to user interfaces.

[thundernixon]

Thanks for adding that thought, Behdad!

only integral values on the axes are intended to be exposed to user interfaces

As a current workaround to signal the intent to users, I have indeed been setting range values with the idea that integers communicate granularity.

Do you think that the integer-only approach might provide implementation advantages over allowing for arbitrary granularity control? Would it be faster to make it into the spec & UI? When you call it a flag, I take that to mean that it would be a bit available to software for interpretation, rather than a feature "built-in" to fonts. In that case, would it really be much more work for either side (OpenType or software makers) if that flag revealed arbitrary granularity?

It does seem like there may be instances in which specific granularity would be helpful to separate from integer values. As far as I can predict, this would be most common in axes which have implicit meaning beyond granularity, but designers still want to enforce some amount of limited options.

A few scenarios that come to mind:

• A Slant axis will typically communicate the angle of slant in degrees (approximately). A designer might want to restrict this to a stepped range, but may not wish for there to be the same number of steps as degrees. For instance, it might be desirable to provide a slant axis that allows values of 0, -7.5, and 15.
• The Width axis is generally thought to be a percentage of the "normal" width at 100(%). Perhaps, a designer would wish to make a font for a client that should have access to values 75, 100, and 125, but not 76, 77, 78, etc.
• A rotation axis may want to use a value of 12 (to align to a clock), but have 60 steps (to align to the minute markers on a clock). Alternatively, it may have a value of 360, but need to impose a granularity of 30 or 6 to align to clock hour or minute markers. Of course, this may be an overly fanciful scenario.

These scenarios might conceivably be coverable by named instances, however. If an integer-only flag really would be possible to implement more quickly, it would probably cover the majority of use cases, and I would be in favor of it as a simplification.

[behdad]

Steps can already be approximated using avar table. So that doesn't need any changes to the spec or implementations. "boolean" and "integral" axes are a natural extension to sliders (toggles and radio-buttons in UI speak). So adding that to the spec makes sense to me.

[thundernixon]

Okay, good point. I am indeed hoping that a small number of steps would be interpreted as toggles / radio buttons / segmented switches in UI.

That's good to know about avar and steps! I'll need to try that to better understand it, but it's good to know that it's a possibility.

I suppose that if an axis has more than a certain number of values and it has an integer-only flag, software makers could decide the threshold below which a toggle works, and above which there is enough change to make a slider feel better.

[thundernixon]

Okay, good point. I am indeed hoping that a small number of steps would be interpreted as toggles / radio buttons / segmented switches in UI.

That's good to know about avar and steps! I'll need to try that to better understand it, but it's good to know that it's a possibility.

I suppose that if an axis has more than a certain number of values and it has an integer-only flag, software makers could decide the threshold below which a toggle works, and above which there is enough change to make a slider feel better.

[behdad]

We should come up with a proposal for that.

[arrowtype]

A proposal for opentype, or for software vendors, or both? Is there a general format for proposals like this, or what would you suggest as next steps?

[arrowtype]

(sorry, signed into another account on my phone; this is still Stephen)

[behdad]

For OpenType.

[thundernixon]

Making a proposal

Is there an example you would suggest following in creating such a proposal, @behdad? My current assumption is that I would create a repo with a readme that details the suggestions here, similar to the XVAR proposal.

Integer vs floating-point steps

I've recently learned that the OpenType 1.8 spec says of the ital axis:

Valid numeric range: Values must be in the range 0 to 1.

This points out one of the biggest reasons for granular steps. It seems likely that web browsers will want the Italic axis to be 0 or 1 for a simple on/off implementation with font-style: italic, but it's also natural that type designers will often wish to give users clear control over what happens in the Italic axis.

One good example is Roslindale Italic Variable.

Different letterforms change at four distinct steps along the ital axis, which can only go from 0 to 1, per the spec. It would be a better user experience in design tools if the font could specify a granularity of 0.25, to make it clear what the possible useful values are.

Another example is one I posted above – but which I now realize violets the spec with an ital axis going from -1 (off) to 0 (auto) to +1 (on). Instead, it should probably have steps at 0, 0.5, and 1.

Presumably, it's likely that future axes may dictate 0 to 1 ranges, as well. In such cases, I bet that there will be a similar desire to specify granularity in fonts. If only integer-level granularity can be asserted, designers may have to make custom axes as workarounds (such as a "Cursive" axis to control italic alternates). This might be fine, but would also probably sacrifice support in basic CSS.