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?
0
Comments
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.
https://events.bizzabo.com/356258/agenda/session/687540
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.
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.
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?
Only Regular -> Bold works reliably
- 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
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
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.