Variable fonts and OpenType features (a theoretical & a practical question)

Ori Ben-Dor
Ori Ben-Dor Posts: 386
edited June 2021 in Font Technology
Theoretical question:

To my understanding, a variable font file is basically just a standard font file with some extra tables (fvar, gvar, etc.) that describe the design space, the deltas, etc.
Does this mean it's impossible to have different kerning information for different masters, given that kerning information is stored in a separate table with no copy-per-master mechanism?

Practical question:

I've got a variable TT file with no kerning information. I've also got a .fea file with a kern feature. I'd like to inject that kern feature into the TT file (with respect to the previous question, I'd like all masters to share the same kerning information). What would be the easiest and safest way to do that? makeotf? Decompile and recompile using ttx? If ttx, how do I safely add the feature to the decompiled file?
Tagged:

Comments

  • Erwin Denissen
    Erwin Denissen Posts: 302
    Variable fonts are so much more than just deltas of the outlines. Hinting and OpenType positioning can also be variable; so single and pair positioning as well as anchor based rules. On top of that you can also include feature variations, which sort of allow for variable substitutions. A variable font can (and should) also contain Named Instances and Axis Values.

    To answer your question, you only need to add the kern feature the way you do it with a non-variable font. That way all other masters will use the default kern values. I don't know any of the tools you mention, but in your case it should be pretty straightforward.
  • Ori Ben-Dor
    Ori Ben-Dor Posts: 386
    I see. Where/how is per-master kerning information stored?
  • Ori Ben-Dor
    Ori Ben-Dor Posts: 386
    Never mind, I think I got it (GDEF). Thanks!
  • Paul van der Laan
    Paul van der Laan Posts: 242
    Kerning is stored in the GPOS ("glyph positioning") table.
  • Ori Ben-Dor
    Ori Ben-Dor Posts: 386
    Yeah, the basic kern feature goes there. But once different masters require different kerning values, the deltas are stored in the GDEF table (specifically in the ItemVariationStore subtable). Am I wrong?
  • Erwin Denissen
    Erwin Denissen Posts: 302
    Default kerning is indeed in the GPOS table, and it also contains information that links to GDEF for the variable data.
  • Simon Cozens
    Simon Cozens Posts: 752
    edited June 2021
    The problem you mention - getting a layout feature into a variable font - is one of the reasons I have been pushing a lot for the concept of variable layout and variable-first building. If you can get access to the ATypI tech talk I did on this, it explains it a lot. (The slide deck for another version of the talk is available here.)

    Yes, the positioning features for the default outline goes in GPOS, and the deltas are stored in an IVS. Putting these in by hand is in insane, and putting per-master layout features into a variable font is currently unpleasant in the open source toolchain - you need to generate individual fonts for the masters, add the positioning rules to each font (since the values will be different) and then merge them together into one font at the end, which computes the deltas and puts them into the IVS. This doesn't work well for any layout rules other than kerning and anchors, because in those cases the per-master values can be derived from the font source file; for more complex rules, you in theory would have to write a per-master feature file, but most font editors don't support doing that.

    My idea is to allow the user to write a feature file in a way that supports variations. There is a draft specification for how to do this with an extension Adobe feature syntax; you can then use my fonttools branch to process variable feature files (with e.g. fonttools feaLib whatever.varfea whatever.ttf), adding the rules to the font binary directly.
  • Erwin Denissen
    Erwin Denissen Posts: 302
    Simon Cozens said:
    My idea is to allow the user to write a feature file in a way that supports variations. There is a draft specification for how to do this with an extension Adobe feature syntax; you can then use my fonttools branch to process variable feature files (with e.g. fonttools feaLib whatever.varfea whatever.ttf), adding the rules to the font binary directly.
    This is also natively implemented in FontCreator:


    You can see it starting at 25 seconds.
  • Ori Ben-Dor
    Ori Ben-Dor Posts: 386
    Thanks, @Simon Cozens, I'll check that out.

Categories