[OTVar] Axes Proposals: variationsguide.typenetwork.com
When OpenType 1.8.0 was released at ATypI last year, Peter Constable and Rob McKaughan at Microsoft said they would be soliciting proposals for new registered axes. With the recent publication of OpenType 1.8.2, now they are 
In working with variation fonts, anyone can make any axis they like, so what is a “registered” axis, and why do they matter? The latest version’s new “Design-Variation Axis Tag Registry” page explains:
...
Microsoft welcomes nominations for new design-variation axis tag registration.
Registration of an axis tag can be useful for two key purposes. One is to foster conventionality and familiarity for a kind of design variation. ... Another key purpose for registration of axis tags is to facilitate interoperability between different fonts or between fonts and applications.
And, how will new proposals be evaluated?
...
It is recommended that the party proposing the new registration seek input from and get consensus among multiple font and software vendors regarding the definition of the proposed axis and its merits.
– https://www.microsoft.com/typography/otspec/dvaraxisreg.htm
Last week week, Type Network published 3 long-form essays on Variable Fonts by David Berlow, which provide context to David’s vision of variable fonts. This follows the soup-to-nuts implementation of that vision in Amstelvar - the first demonstration of this systematic approach to variations for text typography.
This week, David has published an explanation of the system of interrelated axes that Amstelvar has begun to demonstrate, as a proposal for this system to become a set of registered axes:
This proposal does not seek to classify the designs of typefaces parametrically, only what the values of the parameters are. Furthermore, it is offered as a beginning, suggesting the need for—but not containing—suggestions for many important attributes of non-Latin fonts.
The registration of the axes here is also intended to be used as part of a system including the registration of what function an axis performs for programs and/or users along the existing path from script selection to the rendered glyph in a document, aka the Mantra. Documentation of that part of the system, including the registration of what function an axis provides, is still in development and will follow soon.
– https://variationsguide.typenetwork.com
I’ve heard from him that the foundries already part of Type Network will be considering how to upgrade their fonts into this system, and I’m eager for popular libre fonts to do so too.
In first reviewing this system, it seems like a great approach, providing something akin to “primary colors” for typographers to “paint” with.
Comments
-
What about Overshoot axis? Useful or useless?
0 -
Could usefulness be an axis? That way, we wouldn't be forced to choose between useful and useless.7
-
I mean: useful or useless as registered axis (primary type) for type designer and typeface users.Mark Simonson said:Could usefulness be an axis? That way, we wouldn't be forced to choose between useful and useless.
0 -
I guess I should have added a
0 -
This is useful, and this result can be obtained using the ytlc and yopq axes in the proposal, as I understand it.gluk said:What about Overshoot axis? Useful or useless?1 -
Ok,Mark Simonson said:I guess I should have added a
but my question was serious.
For me so one axis was useful (and I used Overshoot axis in my first variable font)
but for normal users so one axis could be too sophisticated. Maybe it would be better if Overshoot would be a part of (for example) 'opsz' Optical size Axis?
0 -
Overshoot, and optical size, axes can be blended out of the primary axes system. That's how opsz is delivered in Amstelvar.0
-
Assuming an axis can be a toggle: we badly need a uniwidth toggle (where set-width is maintained no matter all the other settings). In dynamic typography it's crucial.0
-
.1
-
Hrant, care to expand on that? "Uniwidth" = monospaced?
0 -
Theunis:
Uniwidth has become a useful term to describe fonts whose character widths remains the same across all members of the family. See David Sudweeks’s excellent article for FontShop, Uniwidth Typefaces, which has good examples.
Hrant:
Any axis can be treated as a toggle — if the user or the UI agrees to use only the minimum and maximum states! I think it would be useful for there to be a mechanism enforce this in the spec, so that none of the intermediate states functioned at all (or they snapped to either extreme). This could be achieved, for example, with a flag in the fvar table. Without such a flag, font developers may feel responsibile to ensure all intermediate states are functional.
Your desire for “set-width [to be] maintained no matter all the other settings” would need a more substantial change in the spec. It is fundamental to GX/OT that deltas from each axis are accumulated by addition — it is impossible, in general, with one axis to override the effect of deltas that arise from other axes. Am I correct in understanding that you want to override the effect of other deltas only on certain outline points, such as the advance width point?3 -
..and good luck staying on topic.:)0
-
Laurence, thanks.
In that case I don't see the problem! This far, the usual way of handling a weight change is to change the boldness of a glyph outwards, thus widening the character, but I don't have a problem with an axis that would only change weight inwards. (Or at least without an accompanying advance width change.)
So it would not need to be a toggle anyway.
0 -
This view is too simplistic I’m afraid. The correct way of adding weight whilst simultaneously making sure the shape maintains the same *optical* width is by adding weight both outwards and inwards. Usually around 2/3 outwards, and 1/3 inwards depending on the design.Theunis de Jong said:In that case I don't see the problem! This far, the usual way of handling a weight change is to change the boldness of a glyph outwards, thus widening the character, but I don't have a problem with an axis that would only change weight inwards. (Or at least without an accompanying advance width change.)
And this only applies to the (mostly) Latin-centric view that a glyph consists of two vertical parts (such as in /a /b /h /o for example). For a glyph such as /m it already becomes a different matter.
Also: how do you make glyphs such as /l /i /j /I bolder by adding weight inwards?
3 -
Boolean axes are already possible, no spec change needed. Use the avar table to create one huge step.
Uniwidth is demonstrated in Amstelvar in the grade axis.0 -
Trying to get back on topic, I ask myself (an others) a few simple questions:D. Epar ted said:..and good luck staying on topic.:)
1) Do you fully understand the way Amstelvar masters are constructed?
and WHY they are constructed this way (I mean, the logic behind it)?
2) Have you done any experiment building a family this way? vs building a family using master in the traditional way (masters at extremes and maybe a few in the middle)?
and 3) Do you see advantages in building a family this way? or do you think this will be overkill?
At this time, my answers will be something like this:
1) Not sure I understand it 100% yet. I think I'm getting 75/80% of it, but not all yet. So I need to keep studying it.
2) I did build families in the traditional way and understand how that works, but haven't experimented the Amstelvar method yet, so I'm not completely sure how to isolate each variable in each master as Berlow's did. It will be a nice, challenging and fun experiment to do, but will also take a lot of time.
This year I'm spending most of my week as a single dad with my daughter, and partying like crazy on the free weekends (I'm 40 and I guess I will stop partying next year at 41, and since this will be my last year partying I want to party hard). So I will probably experiment next year.
3) To answer point 3, I will have to experiment first. So take this with a grain of salt... but so far I do think Amstelvar method is a little overkill. I'm guessing that for most web designers, having 3 simple axis will be enough (for example Width, Weight and Optical Size). Anyway... I will love to be proven wrong and will be happy to change my mind in the near future.
4 -
I don't think that would be enough, because the black body has to accommodate the uniwidth-ness.Laurence Penney said:Am I correct in understanding that you want to override the effect of other deltas only on certain outline points, such as the advance width point?
True, but FWIW that's good news: most non-Latin scripts are much less vertical, so it's easier to maintain width with greater weight. Except for Mongolian I guess...Paul van der Laan said:And this only applies to the (mostly) Latin-centric view that a glyph consists of two vertical parts (such as in /a /b /h /o for example).
--
BTW an instructive case here is Axia, which is uniwidth to a surprising extent:
http://typographica.org/typeface-reviews/axia/0 -
Did this document help?Trying to get back on topic, I ask myself (an others) a few simple questions:
1) Do you fully understand the way Amstelvar masters are constructed?
and WHY they are constructed this way (I mean, the logic behind it)?
...
1) Not sure I understand it 100% yet. I think I'm getting 75/80% of it, but not all yet. So I need to keep studying it.
What was your % before reading the document?
Do you have any questions or sense of direction where the missing 20-25% is?0 -
This might be just slightly off topic...
I'm reading the third one now. David says,Dave Crossland said:Last week week, Type Network published 3 long-form essays on Variable Fonts by David Berlow, which provide context to David’s vision of variable fonts...
The fifth registered axis is optical size. This is a treatment, because it does not change the script, class, family or style—just the appearance of a style at a particular size, or range of sizes.
It seems to me that he considers optical-size variation to be a treatment rather than a style because a priori it is assumed that style cannot include optical-size variation. Is that a generally-held perspective?
In the letterpress days, would a case of matrices had different drawers for different weights or widths and also different drawers for different sizes? If so, I suppose from that perspective optical-size variation was conflated with and not independent from text size. But in principle could flip things around by saying that optical-size variation was treated in a parallel manner to weight and width, and text-size was simply conflated with optical size. I guess the physical size is the more visible feature than the subtle changes in glyph design, though.
But I still wonder: in what way is it useful to distinguish between style and treatment in the case of optical size? Earlier in the essay, he gave other examples of treatment, such as how a contour would be stroked or filled. Those involve changing the presentation with the contour staying constant. But with optical-size variation, the contour is changing.
1 -
I'm digesting David's proposed axes. Here's the first one:
I can understand (at one level) what 0 "white" might mean. But it's not clear to me what negative values are supposed to mean.Tag: xtra
Name: x transparent
Description: assigns a “white” per mille value to each instance of the design space
Valid numeric range: -1000 to 2000
Scale interpretation: values can be interpreted as per-mille-of-em
In the demo he provides, he points to the distance between stems of "H" as the xtra value. But it's not clear how that would relate to any other characters, such as "i" or "w" or "ই". Is the idea that the value would be based on glyphs for certain representative character or characters? If so, does it matter if this is done differently in different fonts?
What's the interoperability need for such an axis?
1 -
I think that makes sense because optical compensation is intended to be subvisible: not consciously noticeable by the reader. That said, this should not prevent typographers from intentionally using the "wrong" optical size.Peter Constable said:It seems to me that he considers optical-size variation to be a treatment rather than a style2 -
Laurence,
"It is fundamental to GX/OT that deltas from each axis are accumulated by addition"
This is true. . .
"— it is impossible, in general, with one axis to override the effect of deltas that arise from other axes."
...but when you use the term "addition" it makes it sound like the addition of n + -n "is impossible" to = 0. i.e. it is possible to make an axis that "erases" all or part of another, or erases variations that share the same gvar. Though I care more about understanding than naming things, I think gvars accumulate more clearly than they add.;)
Thanks.
0 -
I might add that my interpretation of the GX model is that any half-axis with a given tag and the scale –1...0 and the half-axis with the same tag and the scale 0...1 are in fact two axes that are mutually exclusive that have been “compressed” into one.
David describes the possible effects of one axis cancelling another — and that's kind of what would happen if you convert the negative "wght" sub-axis and the positive "wght" sub-axis into two real axes, which would then become independent rather than mutually exclusive. Then, one axis would add weight to the neutral master while the other would subtract weight, and the effects could be cumulative.1 -
Ps. Similarly, the fact that we use a 2D coordinate system means that any axis is in fact two axes combined. In TN’s axes proposal, the x adjustments and the y adjustments are split apart into two axes. A conversion of "wght" into a system like the TN proposal can be fully automated (though not there split into the opaque and transparent aspects)1
-
Peter,
I’m going to leave the issues related to axes flags for later, after we finish making, demoing and documenting.
Thanks.
“…what negative values are supposed to mean.”
...is a darn good question that starts us on a path to an extreme answer.;)
In a final composition, transparent space can come and go. Users have the final say as to whether a counter, or inter-glyph space exists or not, as well as how big it is. With variable fonts, for the first time, the internal white space of the letters, the counters... alone... are variable.
Unlike a final print or web composition, where the counter or inter glyph space that's gone, is black, or zero, so to speak, in composing variable fonts, and with overlapping contours, the underlying counter may still exist, as indicated by it's negative number, meaning that counter has flipped.
On operability, while xtra is intended as a hidden axis, programs, or curious users could explore it for all sorts of operability, but first, the selection of the value is an operability leverage point. Being from the same sample in all instances of the axis seems like a reasonable minimum assumption, as this is what ytuc, and ytlc are based on, and no one in their typographic mind changes what in particular they measure, once they start measuring something in particular.
So regardless of what value is chosen as long as it's consistently measured, the xtra axis represents a range of transparent counter values on an axis where nothing else is changing. Also, like any other variation axis, every instance in the entire design space now has an xtra value, and its xtra can be micro-adjusted without damaging the typography. What that gives the variable font is a new thing, from this axis. E.G. change to the tracking/letter spacing, at any instance being used from the variable font, can now share that additional space between the xtra axis and the space being added.
That's a minor interoperability that lots of applications could hook into today, and it's based on not knowing what the value system means beyond relative per mille per axes. Super-interopability is possible when the same value is chosen across variable families, or anytime the same value, like the counter of the H of a non-variable font, can be added to an interested program.
I'll also add, that in the design phase, it was long practiced that the counters of every glyph were recorded on the drawings, and used to drive the suggested range of side bearings in the final type. We can do better with letter by letter xtra adjustments, but I think perhaps that's a generation of apps in the future. For now, this axis value is a summary, but like all the others, every glyph that has a counter, potentially has its own xtra, and every glyph that doesn't have any counter, doesn't have any xtra, which i think a lot of people have figured out, is important in and of itself.
Hope that helps, thanks for the great questions.
2 -
David:
I had wondered if negative xtra values meant that the counter has flipped. But if you want to do that in the x-direction, why not also for ytra?
1 -
Peter,
Well, I thought about it, when I gave yopq negative values. Because it is y stem weight that makes counters flip vertically, I didn’t give ytra a negative range. Could be wrong, easy to fix.2 -
Adam,
Thanks for your comments. I will make more comments about "wght" and "wdth" on Peter's 1.8.2 thread soon. But, the two systems (TN's proposal, and the 1.8.2 spec of width and weight axes), can only be automated one way. So, I don't believe:
"A conversion of "wght" into a system like the TN proposal can be fully automated".
If I understand the spec, to be brief, all of the instances of the "regular" weight, must have a weight value of 400. There are thousands of such regular instances in Amstelvar, (sizes, widths and grades of regular), and I know, as they should, those instances have different weights, so they work as a family of typefaces in typography at all those different sizes, widths and grades of regular.
Removing all the other Amstelvar axes from consideration, I am to label all of Amstelvar's Regulars with 400 wght. This is a simple enough post-process, (as the current wght is per mille, I think), and an “easy fix" for customers who need it. But I couldn’t take a 3 axes variable font, like Amstelvar, where all those Regulars have been labeled "400", and do any more automation with them. I could be wrong but that is not an easy fix.
Thanks.
1 -
So, I don't believe:
"A conversion of "wght" into a system like the TN proposal can be fully automated".
I agree: It doesn't look to me that the existing wght axis scale can be automatically translated into a units-per-mille stem weight scale. I also remain uncertain — but need to read the latest TN proposal document in more detail, now that I'm back from my UK trip — to what that per-mille scale applies. When David discussed this with Peter and me in Berlin, I recall that at one point he talked about applying it to consistent visual weight to a collection of font: even perhaps across a whole library 'so they work as a family of typefaces in typography at all those different sizes, widths and grades of regular'. In which case I was left wondering whether the nominal weight of a per-mille instance in the design space is an absolute stem value — of which stem of which glyph? bearing in mind that this mechanism also needs to be applicable to non-Latin fonts? — or something that might be absolute for some particular instance of one font but optical in others?Automating conversion between a nominal standard value (e.g. 400 = Regular) and an absolute stem weight value looks difficult for the reasons David identifies here. Automating conversion between two nominal weight values, neither of which might actually correspond to an absolute stem measurement, looks impossible.
0 -
[A bit meta:
We have no formal process in place for registering new axes in the new OT Design-Variation Axis Tag Registry. I am wondering whether it would make sense to come up with at least a protocol for how new axes are registered?
I am considering the OpenType Layout feature registry, which is a mess, and how we can avoid a similar situation with OTVar, i.e. features/axes that end up not supported anywhere. features/axes that end up implemented in ways that are not reflected in the registry definitions, features/axes that are redundant and whose function is better handled via other features/axes (whether existing or new).
Something like the W3C publication process seems a good protocol, i.e. new OTVar axes can be proposed, refined by the working group in consultation with the proposers, then published as an official draft, and only formally incorporated into the registry once two independent and compatible implementations exist. As in the CSS or webfont format standardisation process, the draft stage permits and encourages real-world implementation, but it means that the specification doesn't get weighted down over time with things that are not supported, need to be redefined, or maybe even the original proposers have come to regret — as has been the case with several OTL features.]2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports