What is expected of style linking for variable fonts?

Peter Constable

Style linking was brought up in another discussion on variable fonts. I'm wondering what people expect in regard to style linking, and why it matters?

I assume what people mean by style linking is the pairing that is reflected by use of "B" and "I" buttons in app toolbars (or, Ctrl-B / Ctrl-I). Or is there something more that some have in mind I'm missing?

If that is what people have in mind, what's the significance for variable fonts?

Certainly, lots of variable fonts will have a weight axis, and so there's a question of whether bold style linking matters, whether linking between "Regular" (400) and "Bold" (700) is sufficient or if other pairings are desirable, ... What are people thinking?

For "italic", OpenType and CSS make a distinction between italic and slant/oblique, though in the past fonts and apps have conflated the two so that the "I" button could toggle between upright and oblique. In variable fonts, italics are most likely to be treated as a binary pairing, implemented in a separate font. But the OT spec doesn't rule out the possibility of some type designer coming up with a gradual and continuous transition between Roman and Italic (here, I don't mean slant). (On the other hand, CSS assumes italic is binary). With that in mind, what kinds of pairings matter?

And in either case, for whom does such pairing matter? The casual users of word processing apps (Word, Pages...)? Web developers? Users of Figma or In Design?

Craig Eliason

There are a lot of hard questions when aspects like weight become continuous, but I do wish I could figure out with binary italic pairs how to link things (so, for example, in inDesign an upright setting at whatever settings on weight and width axes could be converted to an italic with that same weight and width by pressing Cmd-Shift-I). 

Nick Shinn

It doesn’t matter what people expect, they don’t deserve faux!

Never mind OpenType and Variable fonts, surely ordinary typographers should be able to get proper bold and italic.

If the great software engineering minds can’t get together and achieve this most basic of typographic functions…

Can the variable format help fix that?

Maybe CSS tags like <strong> and “700” should be retired—they are not typographic weights that make sense to typical users of website building apps.

It would be nice for different tech sectors (including typographers) to get together and kill faux.

** 

Consider how Wordpress implements CSS.
(As was noted in a recent thread, it is used to create almost half of web sites—which is where variable fonts are most at home.)

At the moment, the default (without plug-ins or special coding) is that you can’t get proper bold and italic in the same paragraph, only faux. If variable fonts can fix that, great. Something basic and practical to aim for. 

I make this observation as a typographer, having recently redesigned my web site with Wordpress, at which I’m not exactly a power user. It was rather annoying to have to design around not being able, through the strictures of my own good taste, to employ bold and italic styles in running text.

Peter Constable

I had meant to mention Si Daniels ATypI presentation a couple of days ago in which he mentioned font-picker UI changes in Office that will now include an indication of when a faux style is being used.

https://events.bizzabo.com/356258/agenda/session/687540

Thomas Phinney

I have a typeface with a Slant axis, with which I would expect to be able to access a slanted instance via the italic button in any app that has such a button. Does the OpenType spec only support such style linking for an “Italic” axis?

Peter Constable

The STAT table includes axis value subtables that are used to describe particular axis values. At Adobe's request, there was a format for the AVT added that allows a style-link to be declared. But it only allows a mapping to a different value on the same axis. 

Even so, if a VF has a 'slnt' axis rather than 'ital' axis, applications would need to have logic to treat 'slnt' like italic for purposes of the "I" button, and could toggle between a pair of values indicated in the AVT--e.g., 0 and -20.

Thomas Phinney

So it is up to apps (or font-handling libraries/APIs they rely on) to decide whether to support this at all, and whether to do so for 'slnt' as well as 'ital'.

John Hudson

Some font makers apply stepped bold style linking across some members of a weight progression, so e.g.

SemiLight -> SemiBold
Regular -> Bold

which in a static font family is done by aligning the Name ID 1 entries such that the SemiBold is

ID 1 = Fubar Semilight
ID 2 = Bold

I’ve never been sure whether this is a good idea or not: it works, but arguably the intent of the RIBBI name IDs is limited to actual Regular, Italic, Bold, and Bold Italic font styles, and should not be used to create pseudo subfamily style linking.
_____

I agree with Craig that italic style settings—whether applied by an [I} button in the interface, a corresponding keyboard shortcut, or via another kind of style definoition—should result in an italic that corresponds to the weight, width, or any other axis in a variable font of the active non-italic type. So if, for example, a user has dialed a non-named instance of a variable font of e.g. some weight and optical size setting, activating italic style in the text should result in the corresponding instance of the italic font in the same family.

Dave Crossland

I believe Thomas Phinney posted while at FontLab that this was a BAD idea.

Thomas Phinney

Offhand, I would agree with John and Craig; I am not remembering saying it was a bad idea.

If I did say so, I must be forgetting something I knew 3+ years ago? @Adam Twardoch does this discussion ring any bells for you?

Dave Crossland

I seem to recall it was around the release of the victoria era TransType; and that TransType won't do this. 

John Hudson

Not sure what aspect of this you are referring to, Dave. What did Thomas say was a ‘BAD idea’? I am guessing maybe style linking of intermediate weights, but please clarify.

Dave Crossland

SemiLight -> SemiBold

Only Regular -> Bold works reliably

Adam Twardoch

I always thought that the STAT table was designed to allow more flexible style linking in the variable context.  

Adam Twardoch

TransType has several methods to produce styling (style-linking) in the Organize menu. 

- Separate Styling will not style-link anything
- Italic Styling will only link italics to their upright counterparts
- Optimal Styling will ALSO link the "Bold" weight to the "Regular" (and BI to I)

But you can manually drag-drop, say, Semibold to make it the B style of Light. That’s why TransType has the drag-drop UI  

Adam Twardoch

The reason why we’ve done the “optimal” styling this way was not because additional linking of weights would somehow be universally bad, but rather, because linking, say, Black as the B of, say, Light, meant that there was no "MyFamily Black" entry in the font menus that still used Styling Group Names (NID 1), and there was never an easy way for end-users to GUESS which font (say SemiLight or Light) they need to choose and then hit B to get the Black that they ultimately want. 

For Regular > Bold, there is a more-less universally known convention PLUS the "B" buttons in the UIs actually literally say "Bold". So it’s easy to figure out, and to explain: "To get MyFamily Bold, choose 'MyFamily' and click the Bold button." OK. 

But if you start explaining: "To get MyFamily Black, choose 'MyFamily Light' and click Bold because Black is the Bold of Light.", the users will go https://www.youtube.com/watch?v=F8ypNX4cTWE&nbsp;

Adam Twardoch

So our built-in automation will only style-link Bold to Regular, because that’s easily explained to the end-users of fonts, and is “safe”. But in FontLab and in TransType, you can make more “aggressive” style-linking manually: FontLab apps allow it, but then it’s up to the font developers to explain it to their customers. 

Variable fonts may be packaged as one font with the `wght` and `ital` axes or two fonts with just the `wght` axis each (plus other optional axes, but we disregard them). When Microsoft introduced the `STAT` table, my impression was that this was to allow for more flexible style-linking. That’s why you can put the `ital` axis in both the upright VF and the italic VF.

But it turned out that the STAT table offers two mutually-exclusive options: format 3 allows style-linking but no ranges, and format 2 allows ranges but no style-linking. I remember that Sairus Patel made a proposal somewhere to merge format 2 and format 3, but I don’t think this ever came to fruition. (I think this was about using multiple STAT subtables of different formats, with some restrictions, so it wasn’t a fully-new structure).

If we only use STAT format 3, I think it’s possible to express style-linking in a flexible way in either one or many VFs. The font engine that consumes VFs should check the presence of the `wght` and `ital` STAT axes and if the fonts contain STAT format 3, should just utilize the style linking provide there. 

Adam Twardoch

(Oh, and yes, I think the `ital` axis should have precedence, but if the `slnt` axis is present instead, that should be used.)

Peter Constable

Adam Twardoch said:

I always thought that the STAT table was designed to allow more flexible style linking in the variable context.  

Potentially it can be used that way because STAT allows a font to declare specific style-link pairings. That's different from tweaking name IDs 1, 2, etc. to get that effect.