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...
Comments
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.
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.
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.
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.
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.
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.
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.
In a nutshell, Laurence had it right when he wrote:
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.
A more complete definition would be something like this:
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:
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).
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.
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.
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.
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.
Those discussions are now no longer theoretical now that https://github.com/TypeNetwork/fb-Amstelvar provides a font with a grades axis.
Now that we have Amstelvar, how does one go about registering axes?
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?).
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.
I would like to follow the conversation
I would like to join that group too