Is it possible to have two mastes, each with the same gpos feature but different values, and interpolate between the two in a variable font?
No but you can replace features with custom code on a per-instance basis with the custom parameter of the same name.
But, how is this different from interpolating kerning? Isn’t it essentially the same?
The difference is how it is stored in the file. Written feature code (be it GPOS or GSUB code) cannot be interpolated, by its very nature. I take it, this is the case you are referring to, or am I missing something?
On the other hand, the kerning values are stored as numbers and can be interpolated. From these interpolated values, the kern feature code will be generated, and makeotf can compile it into a GPOS table.
Thanks. I understand.
Written feature code (be it GPOS or GSUB code) cannot be interpolated, by its very nature.
But, you can write higher-level code to do such interpolation, and have custom feature files for each instance.
You mean, in Variable Fonts?
I am talking about variable fonts.
Well, @mekkablue wrote,
No but you can replace features with custom code on a per-instance basis with the custom parameter of the same name.
That’s what I’m referring to also.
However, I thought there was some way for in-format interpolation of GPOS values - since it is required for positioning layout of complex scripts like Arabic or Telugu or etc.
I’ll ping the Type Drawers thread about this 
There are a few things mixd up. Variation fonts do not interpolate feature code. They have features that a) respond to instance positions and b) have variation data for some values in the GPOS table.
There’s two separate things here:
-
Interpolation of kerning data during font production, such that interpolated kerning can be applied to intermediate instances in the source design space (or even extrapolated beyond the source design space, if the tool allows that).
-
Interpolation of GPOS kern feature data stored in a variable font.
I view AFDKO .fea kern feature syntax — like corresponding VOLT lookup syntax — only as compiler interface code. It’s not a necessary tool representation, and unlikely to be the best tool representation. What one needs for (1) is a way of interacting with kerning within your tool of choice, including ways to maintain interpolability of kern sets between masters, and ways to perform interpolation within the tool so that one can see kerning applied to interpolated instances and generate interpolated kerning for individual instance fonts. Personally, I don’t think any part of that process should involve a type designer looking at .fea kern feature code, or even needing to be aware that such a thing exists. Kerning in font development tools should be a higher level interface, away from the requirements of a particular compiler, and the tool should look after conversion to compiler interface code in the background.
For (2), one needs the tool to be able to write variable font data to the OT 1.8 format GPOS table. This, like other aspects of OT variations technology, involves storing deltas to default GPOS data, which maps to the design space in the variable font (which may or may not directly correspond to the source design space: it might be a subsetted area of the source design space). The same comments apply with regard to the kerning interface used by the type designer: it should be the same regardless of whether what is being produced are discrete instance fonts or a variable font.
2 Likes
What about contextual kerning?
Good point. I’ll see if I can find a solution for that.
??The tools for this are still not there. I have some ideas but they still need some time.