Variable font build and naming options

[tiroj]

We're working on a variable font build of the STIX Two Text fonts. There will be two variable fonts: one roman and one italic, with a weight axis interpolating between the existing Regular and Bold designs. In future, the variable fonts could be extended with additional axes, e.g. an optical size axis to provide refinements for small caption text or large titling uses.

We're now at a stage where the new variable sources will become the common source for both variable and static fonts. This will ensure compatibility between the variable and static builds of the fonts with regard to glyph shapes, spacing, layout behaviour, etc.. We have some options regarding font naming conventions on which we would appreciate feedback from users and direction from stakeholders:

A. I'm wondering what approach you think we should take for the naming of the variable font? There are a couple of options:

1. Treat static font and variable font builds as separate families. If taking this approach, my usual practice is to include 'VF' in the variable font family name. The benefit of this is that a user can have both static and variable font versions installed, and can use them independently, e.g. in different apps or for different layout purposes.

2. Treat static fonts and variable fonts as different packages of the same font family, i.e. with the same font family naming. In this scenario, the variable font would contain named instances that correspond exactly to the static fonts, which means that e.g. a document created using the static fonts could be displayed using the variable fonts, and vice versa.

I've got clients who definitely prefer one or other of these options. Dave, what approach does Google Fonts favour?

B. In terms of CSS weight classes, the STIX weight axis will traverse the design space between 400 (regular) and 700 (bold). There's room for two standard weight class entries between these extremes: 500 (Medium) and 600 (semibold). My intention is to map these as progressive intervals along the axis, rather than fixed, equal intervals, as this gives better visual results. These can then exist as named instances in the variable font design space, so would appear as if they were static fonts in applications that only access variable fonts via named instances.

This leads to a couple of questions:

3. Should we make these intermediate weights named instances? It isn't necessary for variable functionality, and too many named instances in a variable font increases the number of font menu entries for the family in apps. But maybe there are some instances that users might like to access in this way? We could also, e.g. make the semibold a named instance, but not the medium.

4. If we make either or both of the weight class mappings a named instance, should we also generate and provide corresponding static fonts?

[davelab6]

For (A) I want (2) :)

(B)(3) I want Medium at 500 and SemiBold at 600, as these are 'fallback' instances. The progressive intervals should be mapped in the avar table :)

(B)(4) Generally I want a build script and 'reference' binaries rather than crafted binaries that can't be reproduced on command by anyone; and for the legacy-concurrent static fonts, ideally these are instanced from the VF using fonttools.varLib.instancer, rather than built concurrently.

@m4rc1e will take a look at some point next month I expect, let me know if you would like him to take a look sooner :)

[tiroj]

Yes, re. B3: the nominal, progressive weights would be mapped in avar to the 500 and 600 values (already the case in the demo build VFs).

Re. B4: I'm trying to get to the stage where we don't need build scripts and can just spit out variable and static builds from the same tool chain. For the STIX fonts, I think we're pretty close on everything except the STAT table using FontLab 7.

I understand why you want a build script, but that's something I need someone else to make for me, on top of the work I'm doing, so it's the opposite of reproducible for me. :)

[davelab6]

@tiroj Marc will take a look this week

[m4rc1e]

Do we have the VFs in a branch I can inspect?

John, I'll try and get you the conjunct data this week as well.

[tiroj]

No VF yet. I earlier made an alpha build available to Dave and the STI Pub folk, which demonstrated the weight interpolation and GSUB working correctly, but then we ran into issues with FL7 mark feature generation. So that set us down the path of converting anchors and kerning from VFJ sources to VOLT data, with the idea that we could create compatible projects for axis extrema TTFs, and use FontTools to build the variable font. The first part of that work—converting FL7 anchors to VOLT lookups and groups—is done and released under MIT license: see VFJ Tools repo.

@khaledhosny is now working on the kerning conversion. This is more complex because subtable optimisation needs to be done prior to generating the VOLT lookups. So far as I am aware, there is no existing open source code to do this—FontLab licenses Karsten Luecke’s code—, so Khaled is working from scratch. [In the meantime, FontLab has just released a new version with its own VOLT-export capabilities, but I have not tested this yet or confirmed what it does with anchor and kerning data.]

---

STI Pub are going to be setting up a private repo for pre-release testing and delivery of STIX builds, and plan to have a couple of seats for you and Dave; let me know if you need additional Google Fonts seats.