[OTVar] Axis Interaction and Literality

Hrant Հրանդ Փափազեան Papazian

In discussing the inter-relation of axes with @Laurence Penney it struck me that there's a conundrum here that might need to be resolved sooner rather than later (although it's possible others have actually already worked through this).

Consider a typeface with weight and width axes. We know that –at least conventionally– adding weight adds set width to a font, arguably to maintain apparent width. The question becomes, should a width axis then be considered "non-literal"? Because the set width would change with weight but without actually changing the position on the width axis... This is probably not intuitive in terms of user expectation, although it seems like a logical compromise for designers who have grown up on discrete weights/widths. Also, it makes it rather intractable to maintain set width (in the absence of a uniwidth toggle).

I posit that in this new continuous-axis world there's another approach that might be more intuitive for users: the weight axis maintains set width; this would cause a shift in apparent width, but the width axis would become literal (as the weight axis is); a uniwidth toggle would become redundant; and any apparent-width compensation would be done manually via the width axis. Of course this gives the user more power, but also arguably a responsibility that might backfire; the type designer's expert judgement of the relation of weight and width becomes lost, and is difficult to replicate.

So maybe an interface could provide a choice between Set Width and Apparent Width...

Hrant Հրանդ Փափազեան Papazian

Note that this issue also applies to weight versus x-height for example (where an increase in the former is suppose to cause an increase in the latter) and I guess any axis that potentially hinges on some literality.

Ray Larabie

...arguably to maintain apparent width.

I would think literally altering weight and width axes would be a rare case. Perhaps for symbol fonts, dingbats, scientific use?

When you discuss the idea of uniwidth, what do you envision the practical purpose to be? I can see how it would work in monospaced typefaces...but with proportionally spaced type, how would it be used?

If I make a weight axis, it's possible to maintain even width for some letters. Like the letter H. If I maintain the advance width on the weight axis, I can change the weight of HHHHHHHHH without altering the line length. Of course, the width of the H would have to get narrower at the light end of the axis to allow for wider sidebearings* but it's possible to maintain an identical advance width for the H throughout the weight axis. But throw the letter I in the mix and you can't mainting the same advance width. A heavy I can't have the same advance width as a light I unless it's designed like a serifed monospaced I. Same goes for anything narrow like comma, period, quotes etc.

* Since it's inconceivable that a weight change wouldn't alter the sidebearings, it's very unlikely that a proportionally spaced fonts contain literal width and weight axes...apart from the aforementioned monospaced and scientific uses.

Laurence Penney

Twitter thread: https://twitter.com/hhpapazian/status/829090133064314880

Laurence Penney

The fundamental point is that variable axes in practice – whether Ikarus, Metafont, MM or GX – almost always work optically, not geometrically. In other words, it has usually been desirable, for ease of use, that a change in weight causes actual glyph widths to change, and for a change in width to cause geometric weight to change.

Laurence Penney

Related… This experiment uses a font’s width axis to allow you to pull around text box handles, while the font adjusts width to suit, only using a purely geometric transformation when beyond the bounds of what the font’s axes can achieve. It feels very different, depending how far the actual characters in the box can be adjusted. Thus a string of I’s won’t do much before falling back to geometric, but a string of M’s will have a lot of leeway in the axes, before geometric. I also added a weight axis, which chooses the appropriate width axis setting to maintain the text box size.

http://www.axis-praxis.org/blog/2016-11-24/10/demo-resize-textbox-with-variable-fonts

Try it live with Safari Technology Preview or Webkit Nightly.

Kent Lew

The question becomes, should a width axis then be considered "non-literal"?

In the sense you’re talking about: Yes.

This is probably not intuitive in terms of user expectation,

Really? Are there users who expect to change the weight of a font and not have a line length change to some degree?

I imagine that for those situations where users want to be able to change weight interactively and have line length stay constant, there will be secondary mechanisms and plug-ins that will calculate and manage such for you from within the provided weight/width matrix.

Although the idea you keep advocating may have some value for certain designs or certain use cases, I don’t think that it is necessarily a preferable default behavior moving forward.

Hrant Հրանդ Փափազեան Papazian

> I would think literally altering weight and width axes would be a rare case.

Isn't that what graphic designers do? Athough sure, much of it will be under-the-hood. But those designing the engine might still get confused...

Uniwidth: the core benefit is that you can change the weight without affecting the bounding box / text flow, for medium/environment compensation or dynamic/flexible emphasis. The idea of "grade" does handle that, but I think it's become legacy baggage in this age of continuity; more elegant would be to separate width staticness and gain compensations.

The problem with uniwidth is that beyond a range of weight it starts affecting the apparent width enough to alter the character of the face*, so it should be a toggle.

* Or maybe not: http://typographica.org/typeface-reviews/axia/#comment-68360

> But throw the letter I in the mix and you can't mainting the same advance width.

True, although you can fudge the weight and spacing up to a tolerable point, at least within a weight range; a font is a lattice of compromises anyway. But certainly uniwidth is worse for some designs; it's optional.

> variable axes in practice – whether Ikarus, Metafont, MM or GX – almost always work optically, not geometrically.

But people –especially designers– often have geometric expectations, at least for axes involving alignment, like width and x-height.

> Are there users who expect to change the weight of a font and not have a line length change to some degree?

I think the expectation that weight affects width is non-intuitive and something simply acquired through experience derived from discrete weights. I strongly suspect that over time spent with continuous axes people will become increasingly confused by the set width changing while an ostensibly-literal width axis is staring at them unchanging...

I think at the very least a non-literal width axis should be called Apparent Width, to drop a hint that "it's not that simple".

> there will be secondary mechanisms

Why secondary?

BTW, I think the calculcations would be non-trivial (and possibly non-exact)* and the type designer actually including a uniwidth option is the robust approach. Many fonts won't have that option, but the more dynamism and continuity become established the more it will become a demanded feature.

* Like that Axis-Praxis demo having to iterate in a way I might describe as feverish...

--

Maybe there should be a global toggle to link/unlink axes.

John Hudson

So maybe an interface could provide a choice between Set Width and Apparent Width...

There's no point in an interface providing that choice if a given variable font isn't designed to work that way. As Kent suggests, it might be possible for a variations display engine to interpret the font design space in a way that enabled it to maintain stroke weight in width variations, or vice versa, but a) that's not trivial and involves something between the font and the user interface, and b) there would still be limits on such a process determined by how the font has been designed and the relationship of masters in the design space. It's still, ultimately, up to the individual font.

Amstelvar makes a distinction, using custom axes, between weight/width and paraweight/parawidth. I've not had time to experiment with it, but I believe this is an example of a distinction between optical and geometric.

it struck me that there's a conundrum here that might need to be resolved sooner rather than later

Not a conundrum; nothing to be resolved. Designing a variable font is about designing a design space. Insofar as a variable font has capabilities beyond the set of named instances constituting individual typeface designs, these subsist in the design of the design space. If variable fonts are ever going to be marketable as other than efficient packaging of multiple instance fonts in a single file, font makers will need to create useful and innovative design spaces (presuming, of course, someone else is creating useful and innovative user interfaces to access those design spaces). The design space is the product.

Constraining the meaning of axes—even common, registered axes—to specific design approaches means constraining the design space. Font makers would inevitably want to break such constraints, so rather than encouraging a proliferation of non-standard and incompatible custom axes to bypass the constraints, I think it makes sense to impose as few constraints as possible up front. So the relationship between weight and width axes should not be presumed to be either optical or geometric, as a rule, but should rather be a choice in the creation of the design space of particular fonts. There are designs and uses for which an optical relationship makes sense — many such, since this is by far the common model of typeface design —, and designs and uses for which it makes sense to impose a linear, geometric relationship. Either can be expressed in a variable font design space; if your brain work's like David Berlow's, maybe both can be expressed in the same design space (it does my head in).

There is, of course, an argument to be made for standardisation, for defining at the specification level what the relationship between axes should be. It's the same argument that has existed since the beginning of casting moveable type in metal, and that finds expression in ideas around redefining type size in terms of x-height, or matching CSS weight classes to actual stem weights. In my experience, it's an argument that can't cope with the variety of design, especially not across the variety of global writing systems. There may well be font makers who decide to build all their variable fonts in a particular way, to constrain their design approaches to those methods, and they will be able to market that consistency as a feature of the design spaces of their fonts. There will be other font makers, perhaps dealing with different scripts, or simply with novel kinds of design, for whom those methods are either inapplicable of simply not appealing. And as William Blake observed, one law for the lion and the ox is oppression.

Hrant Հրանդ Փափազեան Papazian

> There's no point in an interface providing that choice if a given variable font isn't designed to work that way.

Agreed. But since I think many of them will be, we should be prepared to address this.

I will look closer at Amstelvar. Suffice it so say that looking closer does seem to be required...

Type designers get it, but a user looking at an unchanging continuous "Width" while the set width changes is most probably a problem (and related to why that Axis-Praxis demo has to work hard –and never to exactitude– behind the scenes). I guess it's the classic balancing act between convenience and education.

> Constraining the meaning of axes—even common, registered axes—to specific design approaches

Not design approaches, but user expectation. Design is for users. Demanding that users understand the non-literality of Width seems dogmatic.

> I think it makes sense to impose as few constraints as possible up front.

That's a good argument. Then I would say the concept of "standard axis" is problematic, and designers should name their particular axes judiciously. To be clear, I certainly don't mean that axis naming should constrain design.

John Hudson

Demanding that users understand the non-literality of Width seems dogmatic.

Given that 550+ years of typographic text has overwhelmingly involved optical interaction of weight and width, as a responsibility of the typeface maker, it would seem to me at least as dogmatic and distinctly less viable to demand that users become responsible for adjusting these as entirely independent variation vectors. There's a lot of presumed knowledge and experience in such a responsibility: the knowledge and experience that type designers spend years developing.

I would say the concept of "standard axis" is problematic

Think it through. Standard axes provide a means for fonts to interoperate with well-established functionality in applications, CSS, etc..

Rob McKaughan

In a nutshell, Laurence had it right when he wrote:

The fundamental point is that variable axes in practice – whether Ikarus, Metafont, MM or GX – almost always work optically, not geometrically.

It also doesn't help that he OpenType spec's definition of width is incomplete. (more on that below).

Forgetting variable fonts for the moment, we have a number of longstanding conventions and expectations in typography. It's reasonable to expect that two bits of text set in the same weight, but different widths (e.g. a headline deck), should still have the same typographic color across them. It's also conventional for typeface to add/remove width as they add or remove weight. (And, duplexed bolds are another convention). These are all things that folks are used to and thus changes in typesetting specs have predictable results.

And we hope to have the same predictability with variable fonts. If I choose a particular weight, then all text set in that weight should have the same typographic color, regardless of how the width, optical, wonkiness, serifness, formality, and other axes are set. Or, if I've got a layout that takes advantage of optical size throughout, but decide to reduce the widths dynamically (to fit in portrait mode on a phone), then the relationships of weight, optical size,  etc should remain consistent through that transformation.

So, pragmatically, it's easier to have these adjustments focus on the optical results rather than the mathematical / geometric results.

It also makes it easier to have automatic layout adjustments (like the width one I mentioned above). Ultimately, it's the optical impact to the reader that matters. We could keep everything mathematically pure, but I don't think anyone's figured out how to map geometric/mathematic adjustments to optical impact (if they had, it'd make type design soooo much easier - you could auto-generate an entire typeface family from a base skeleton).

Coming back to the width axis: the problem is the OpenType specification's definition of coordinates for the width axis is incomplete. It defines width coordinates relative to the normal width (which is defined at the discretion of the type designer), but it doesn't say what's going on with the other axes in the font.

Values can be interpreted as a percentage of whatever the font designer considers “normal” for that font design.

A more complete definition would be something like this:

Values can be interpreted as a percentage of whatever the font designer considers “normal” for that font design, with all other axes values held constant.

This means that if you have a Bold Display with a width of 1.0, and another with a width of 0.5, both these instances would, typographically and optically, have the same apparent width and optical size. This makes the effects of a change along one dimension feel typographically constant in other dimensions. E.g. if I changed the size (thus optical style) of those two instances, they would still feel the same weight and relative width (one being half as wide as the other).

Another way you could define it would be as follows:

Values can be interpreted as a percentage of whatever the font designer considers “normal” for that font design, with all other axes values set to their default value.

This gives us the more geometric interpretation. If you change the weight, the linear width must remain constant because the width coordinate refers not to the "normal" for the given weight, but the "normal" of the regular weight, no matter what weight you're actually using.

There are a number of difficulties with this. First off, it gives you no way to find the conventional bold for a font - i.e. one where the width naturally is a little wider for the weight (just like my beltline). There's no way for the type designer to tell the user, without further file format architecture, what he or she considers the natural light/bold from the regular. And, you need a more sophisticated user who knows how to adjust both those knobs in unison.

But consider optical size: given this, if I have an optical size axis, then as the size goes up, optical size changes get applied - except one of the most important ones: width. If you want to get the full benefit of optical size in this model, you'd need to move size, width, and weight in concert. And again, there's no way for the type designer to express their design intent of how those knobs should move.

And, it would be impossible to have automatic optical size as there's no way for the operating system to know what the right weight and width adjustment are for size for a given typeface design.

By defining width relative to normal, with everything held constant (my first definition above), it makes the results of a given change relative, which makes it easy to preserve typographic continuity. It also gives the type designer full control over how she/he believes weight, width, optical size, (and any other axis) should move together. It also makes automatic adjustments like optical size easier to implement. 

(apologies for the long-winded reply. I someday I will learn brevity).

Thomas Phinney

Rob, I'm probably just missing something because I am tired, but couldn't/shouldn't your first option also allow for the meaning of a 1.0 width to vary with optical size, just as it varies with weight?

Peter Constable

The intent for defining the width axis was to build on existing practice, and add potential for algorithmic operations to fit text.

In regard to existing practice, if a (non-variable) family of fonts have (say) weight and width variants, such as "Condensed" and "Condensed Bold" and "Condensed Black", a given string at a given text size might have the same line length when formatted with each of these fonts, but very often they would not. The implication is that width, as an axis of design variation, is not necessarily the only axis of design variation that affects the horizontal metrics of glyphs or strings.

In regard to algorithms for fitting text, the thinking was that if the length of a given string at a given text size when formatted with a variant having a wdth axis value of (say) 0.81 would generally be roughly 90% of the length when formatted with a variant having a wdth axis value of 0.9 -- other axis values remaining constant -- then that could be used as a starting heuristic for automatically selecting a new wdth value to format text to achieve a desired line length, allowing lots of interesting possibilities.

The definition for the wdth axis given in the OT spec basically assumed that the first was a given, since that is how most type designers had already been doing things, in practice for years. So, it was written with a focus on the later -- ability to predict a string length relative to a known length for a particular width value. But that also left out an element that was, in fact assumed, something that Rob called out above: "with other axis values held constant". I think it would be good to add wording along that line to the definition in a future update of the OT spec.

Bhikkhu Pesala

I forget the font name now, but I came across a font that was designed to have the same line length for regular and bold. This has a distinct advantage in that applying bold to some text does not alter the text flow.

The Gotham type face has this feature (at least for tabular figures), which is another good reason for not increasing the advance width to accommodate changes in weight.

Sabon is another type face that is designed in this way.

Deleted Account

I am delighted to see a turn toward the road to a better spec.

John Hudson

Sabon is another type face that is designed in this way.

The Linotype machine version of Sabon was designed that way, because of the duplexing of designs on the same set of matrices. The foundry version, for handsetting, was not designed this way. Photo and digital type versions were based on the Linotype machine version, except for Jean François Porchez's Sabon Next, which went back to Tschichold's design for the foundry version and removed the artefacts of duplexing.

There are specific situations in which retaining widths while increasing or decreasing weight is desirable, and many in which it is not. It is also something that only certain designs can accommodate, and something that some of the world's writing systems handle better than others. Hebrew square script, for example, handles it very well, since weight is mostly gained vertically. South Indian scripts with sequential horizontal bowls do not, especially in sans-like designs with low stroke modulation.

Again, this is all design-specific, all font-specific. There's simply too much variety in the shape sets of the world's writing systems and in the creativity of type designers to force a single rule about the relationship of weight and width variations.

Rob McKaughan

Thomas Phinney said:

Rob, I'm probably just missing something because I am tired, but couldn't/shouldn't your first option also allow for the meaning of a 1.0 width to vary with optical size, just as it varies with weight?

Yes. By making the design relative to the normal "with all other axes constant", you can have a 1.0 width and vary optical size and have the appropriate width changes take place that are typically built into optical styles (or natural weights). I.e. the normal width is not fixed at a single value, but varies across the design space, as the designer chooses, along the line/plane/volume of width=1.0. E.g. normal width (1.0) for Display is different than for Caption.  

If you use the other definition ("with all other axes set to default values"), then a run of text must remain the same length while you vary optical size or weight.

That's why I like the first better.

Peter Constable

Bhikkhu Pesala said:

I forget the font name now, but I came across a font that was designed to have the same line length for regular and bold. This has a distinct advantage in that applying bold to some text does not alter the text flow.

There certainly can be useful benefits for designing fonts this way. But that doesn't mean that all fonts should or will be designed that way. And it also doesn't mean that the way that the wdth axis is defined in the OpenType spec should impose that as an expected constraint on how that axis is used.

Bhikkhu Pesala

Peter Constable said: And it also doesn't mean that the way that the width axis is defined in the OpenType spec should impose that as an expected constraint on how that axis is used.

I was not suggesting that it should, just that there might be good reasons for having an option to lock the axis, as there is an option to lock the aspect ratio in drawing programs. 

John Hudson

I was not suggesting that it should, just that there might be good reasons for having an option to lock the axis, as there is an option to lock the aspect ratio in drawing programs. 

It's tempting (indeed, it has been suggested in previous discussions regarding a possible grades axis), but I don't think one can escape the fact that in order for such an option to work well it needs to be taken into account during the type design process, at which point one would do better to implement static width control within the design space. I don't see value in an option to lock axes that are not designed to be locked.

Dave Crossland

John Hudson said:

I was not suggesting that it should, just that there might be good reasons for having an option to lock the axis, as there is an option to lock the aspect ratio in drawing programs. 

It's tempting (indeed, it has been suggested in previous discussions regarding a possible grades axis),

Those discussions are now no longer theoretical now that https://github.com/TypeNetwork/fb-Amstelvar provides a font with a grades axis.

John Hudson said:

but I don't think one can escape the fact that in order for such an option to work well it needs to be taken into account during the type design process, at which point one would do better to implement static width control within the design space. I don't see value in an option to lock axes that are not designed to be locked.

Now that we have Amstelvar, how does one go about registering axes?

John Hudson

There's an ad hoc group looking at grades. What David's done in Amstelvar is both interesting and very clever, but we're not sure how far it works as a model for more typical families, for variable fonts derived from existing font sources not built in that way, or for designers who don't think the way David does.

At the moment, it's not clear that the kinds of variation that might occur in a family with grades is sufficiently similar to be standardised as a registered axis. Nor is it clear what higher level layout and output technologies could plug into a grade axis, and to what end. In reporting on how the Poynter grades are used, for example, Tobias identified at least three different scenarios, none of them obviously automatable in terms of selecting an appropriate grade. So it's possible that grades are not in fact a suitable axis for registration.

cf. my response to your query re. 'privileged' axes, in which I talk about the uses and implications of registration (and suggest a documentation repository for custom axes, which perhaps Google would like to host?).

Ray Larabie

Is grade the same thing as an optical gain. I'm not sure what it's called but I've had to do it for a couple of clients. Let's say you have a medium weight that's displayed light on a dark background on television. But sometimes you need display dark on light without changing the apparent weight... like a selection highlight. When I've done it, it was similar to a stroke effect, a generally fattening up or lightening that doesn't affect metrics. Is that what grade is?

Dave Crossland

John Hudson said:

There's an ad hoc group looking at grades. 

Who is part of this privy council? How does one follow its discussions? How does one contribute to those discussions?

Dave Crossland

Ray Larabie said:

Is grade the same thing as an optical gain. I'm not sure what it's called but I've had to do it for a couple of clients. Let's say you have a medium weight that's displayed light on a dark background on television. But sometimes you need display dark on light without changing the apparent weight... like a selection highlight. When I've done it, it was similar to a stroke effect, a generally fattening up or lightening that doesn't affect metrics. Is that what grade is?

Yes

John Hudson

Who is part of this privy council?

It's not a privy council, it's an ad hoc group made up of people with experience of making font families including grades, and people who wrote the fvar and stat table specifications in OT 1.8. It's exploratory, looking at whether there actually is enough commonality in implementation of grades to establish a common scale for a registered axis and whether such a registration would be useful. If it looks feasible, the process would then go to the group working on the OT specification, which is indeed a privy council.

John Hudson

Is grade the same thing as an optical gain.

Maybe. Can be. Obviously not.

The only common definition of grade that I've been able to come up with is 'A variation of a typeface in which one or more aspects of the design are systematically modified across the whole glyph set without affecting advance widths'.

Use of grades has tended to involve output conditions: variations for different presses, different papers, even humidity levels in the printing plant. But Tobias Frere-Jones also reported that some customers had preferred a particular grade of Poynter simply because their newspaper traditionally had fairly heavy type.

I'd also conceived of optical gain for reversed text as a use case for a grade axis, but then Erik van Blokland suggested that optical gain might be independent of grade adjustments for particular output.

Now I am wondering whether there is, in fact, enough commonality for a single grade axis, or if we would be better with a number of grade-like axes—i.e. not affecting advance widths—with specific kinds of design variation.

Dave Crossland

John Hudson said:

Who is part of this privy council?

It's not a privy council, it's an ad hoc group made up of people with experience of making font families including grades, and people who wrote the fvar and stat table specifications in OT 1.8.

Where does this ad hoc group discuss these things?

I would like to follow the conversation  

 the group working on the OT specification, which is indeed a privy council.

I would like to join that group too

John Hudson

Dave, you should probably contact Behdad and Sascha. I don't know how Google internally decides whom to have as representatives.