Variable fonts and OpenType features (a theoretical & a practical question)
Ori Ben-Dor
Posts: 386
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?
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:
0
Comments
-
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.2
-
I see. Where/how is per-master kerning information stored?0
-
Never mind, I think I got it (GDEF). Thanks!0
-
Kerning is stored in the GPOS ("glyph positioning") table.
0 -
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?0
-
Default kerning is indeed in the GPOS table, and it also contains information that links to GDEF for the variable data.
0 -
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.0 -
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.2
-
Thanks, @Simon Cozens, I'll check that out.
0
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