Problem building a variable font with contextual kerning #4077

devosb · 2026-03-30T18:25:09Z

devosb
Mar 30, 2026

With the font Namdhinggo fontmake cannot build a variable font.

The command used is

fontmake -m source/NamdhinggoUpright-VF.designspace -o variable --feature-writer None

The output is

INFO:fontmake.font_project:Loading 2 DesignSpace source UFOs
INFO:fontmake.font_project:Building variable fonts variable_ttf/NamdhinggoUpright-VF-VF.ttf
INFO:ufo2ft:Pre-processing glyphs
INFO:ufo2ft.filters:Running interpolatable DecomposeComponentsIFilter
INFO:fontTools.cu2qu.ufo:New spline lengths: 1: 190, 2: 2797, 3: 1669, 4: 499, 5: 105, 6: 26, 7: 4
INFO:ufo2ft:Building OpenType tables for Namdhinggo-Regular
INFO:ufo2ft:Building OpenType tables for Namdhinggo-ExtraBold
INFO:ufo2ft:Building variable font: NamdhinggoUpright-VF-VF
INFO:fontTools.varLib:Axes:
[{'axisLabels': [],
  'axisOrdering': None,
  'default': 400.0,
  'hidden': False,
  'labelNames': {'en': 'Weight'},
  'map': [(400.0, 400.0),
          (500.0, 500.0),
          (600.0, 600.0),
          (700.0, 740.0),
          (800.0, 800.0)],
  'maximum': 800.0,
  'minimum': 400.0,
  'name': 'weight',
  'tag': 'wght'},
 {'axisLabels': [],
  'axisOrdering': None,
  'default': 100.0,
  'hidden': False,
  'labelNames': {'en': 'Width'},
  'map': [(100.0, 100.0)],
  'maximum': 100.0,
  'minimum': 100.0,
  'name': 'width',
  'tag': 'wdth'},
 {'axisLabels': [],
  'axisOrdering': None,
  'default': 0.0,
  'hidden': False,
  'labelNames': {'en': 'Custom'},
  'map': [(0.0, 0.0)],
  'maximum': 0.0,
  'minimum': 0.0,
  'name': 'custom',
  'tag': 'XXXX'}]
INFO:fontTools.varLib:Internal master locations:
[{'custom': 0.0, 'weight': 400.0, 'width': 100.0},
 {'custom': 0.0, 'weight': 800.0, 'width': 100.0}]
INFO:fontTools.varLib:Internal axis supports:
{'custom': [0.0, 0.0, 0.0],
 'weight': [400.0, 400.0, 800.0],
 'width': [100.0, 100.0, 100.0]}
INFO:fontTools.varLib:Normalized master locations:
[{'custom': 0.0, 'weight': 0.0, 'width': 0.0},
 {'custom': 0.0, 'weight': 1.0, 'width': 0.0}]
INFO:fontTools.varLib:Index of base master: 0
INFO:fontTools.varLib:Building variable font
INFO:fontTools.varLib:Loading master fonts
INFO:fontTools.varLib:Generating fvar
INFO:fontTools.varLib:Building variations tables
INFO:fontTools.varLib:Generating avar
INFO:fontTools.varLib:Generating MVAR
INFO:fontTools.varLib:Generating HVAR
INFO:fontTools.varLib:Merging OpenType Layout tables
fontmake: Error: In 'source/NamdhinggoUpright-VF.designspace': Generating fonts from Designspace failed: 

Couldn't merge the fonts, because some values were different, but should have
been the same. This happened while performing the following operation: GPOS.ta
ble.LookupList.Lookup[4][0].ChainPosRuleSet[0].ChainPosRule[14].PosLookupRecor
d[0].LookupListIndex

The problem is likely to be in Namdhinggo ExtraBold:
Expected to see .LookupListIndex==19, instead saw 5

I can build a variable font by copying features.fea from the ExtraBold UFO to the Regular UFO, but (not surprisingly) the kerning is not correct in the lighter weights. So the features and lookups are correct, and we can build (with our own wrappers around ufo2ft and fontTools) static fonts that kern correctly.

The issue (when the feature files are not identical) comes from the IkarKWid lookup. The positioning rules are contextual, and I can build a variable font , if I have some subset of the rules. To illustrate, using only the rules towards the end of the lookup (content below is from the the ExtraBold master UFO)

        pos ikar_kemphreng-limb' <0 0 184 0> ra-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 162 0> la-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 173 0> wa-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 111 0> sha-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 329 0> ssa-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 87 0> sa-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 145 0> ha-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 80 0> gyan-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 149 0> tra-limb akar-limb;
        pos ikar_kemphreng-limb' <0 0 184 0> vowelcarrier-limb akar-limb;

Does not compile, the error is

Couldn't merge the fonts, because some values were different, but should have
been the same. This happened while performing the following operation:
GPOS.table.FeatureList.FeatureRecord[1].Feature.LookupListIndex[0]

The problem is likely to be in Namdhinggo ExtraBold:
Expected to see [0]==15, instead saw 14

But if I remove the line with ra-limb, then a variable font can be built. But the line with ra-limb per se is not a problem, since the build works if first 5 lines (ra-limb through ssa-limb) are used (ssa-limb is the glyph that needs the most kerning, so it makes for a good visual test).

A chat with Claude Haiku 4.5 using Copilot Free in VS Code suggested reducing the number of glyphs that needed kerning, or reducing the number of different kerning amounts by grouping some glyphs together. Reasonable questions to ask for a Nastaliq font, but for Namdhinggo, the GPOS is not that complicated. And I suspect I have encountered this issue with other fonts.

After a bit more chat Claude provided a clue

When fontTools compiles contextual positioning rules with many different adjustment values, it can create different numbers of internal simple lookups depending on how it optimizes them. If Regular generates 19 simple lookups but ExtraBold generates only 5 (or in a different order), their ChainPosRule indices won't align during the variable font merge.

With the short example from the ExtraBold master shown above (ra-limb through vowelcarrier-limb) the build works if I change the kerning amount for vowelcarrier-limb to 185. This seems to match what Claude is saying since now ra-limb through vowelcarrier-limb will not share an implicitly generated GPOS Type 1 Single adjustment positioning lookup (I think that is what Claude means by internal simple lookups).

A variable font build can still work even if both ra-limb and vowelcarrier-limb are kerned 184 in ExtraBold as long as those glyphs have a consistent kern amount in the Regular master UFO. So changing vowelcarrier-limb to 187 in Regular (ra-limb in Regular is already 187), with both glyphs in ExtraBold kerned 184, builds a variable font.

If I build the static fonts (compiled with fontTools), and dump them to JSON using ttj, I think I can see the issue better. ttx would also show the difference, but the less verbose output of ttj makes the patterns easier to see in Meld.

Interesting that the first difference, mentioning lookups 19 and 5, match the first error message in this issue. I can understand if I was trying to merge the static fonts into a variable fonts that fontmake would have problems merging all the lookups together, but when building a variable font from the UFO and FEA sources, I am surprised that, AFAIKT, the same issue (the single type lookup being re-used) occurs.

Especially surprised considering that fontmake/fontTools can infer kerning values even if the lookups don't match up between masters, as mentioned in an issue on fontc.

Answered by khaledhosny

Mar 31, 2026

feaLib will certainly reuse implicit lookups whenever possible (and when it doesn't, that is usually considered a bug). Your two options is to either 1) not use implicit lookups 2) use variable scalars so that fotmake/ufo2ft cimpile the layout tables once, instead of one master at a time then merging the binary tables.

View full answer

behdad · 2026-03-30T19:38:17Z

behdad
Mar 30, 2026
Maintainer

Does any of those kern pairs happen to have 0 value in the default?

0 replies

devosb · 2026-03-30T20:16:01Z

devosb
Mar 30, 2026
Author

No. The FEA in the UFOs is generated from a different source file, and there is a conditional that only outputs the positioning rule if the kerning is greater than zero.

0 replies

behdad · 2026-03-30T20:19:12Z

behdad
Mar 30, 2026
Maintainer

there is a conditional that only outputs the positioning rule if the kerning is greater than zero.

That sounds it might be the problem though, no? The feature files should be structurally identical across masters. The merger knows how to deal with differences in kern lookups, but not in contextual lookups.

0 replies

devosb · 2026-03-30T21:47:37Z

devosb
Mar 30, 2026
Author

The conditional might be an issue, and that leads to another question.

First, though, for Namdhinggo, in the IkarKWid lookup, I think the FEA is currently structurally identical across masters. Between the masters the following is true

The number of rules is the same
The glyphs in the rules are the same
The order of the glyphs are the same

What is not structurally identical across masters, if I understand that term correctly, is the implicitly generated GPOS Type 1 lookups that hold the actual kern values, since those lookups get re-used if another rule (in the same master) has the same kern value. That re-use seems like a good optimization for building static fonts, for building variable fonts, can that re-use be turned off (or applied after the features are merged) in fontTools?

The second question could be relevant to Namdhinggo. It is a judgment call (so could go either way), but it is very plausible that one of the masters would need an extra rule in the FEA to kern one additional consonant (compared to the other master). Then the FEA would not be structurally identical across masters. Could fontTools, after detecting that situation, output additional lookups that did no kerning (in the master without the additional rule) so that the generated lookups would be structurally identical?

0 replies

behdad · 2026-03-30T21:50:08Z

behdad
Mar 30, 2026
Maintainer

As I said, fonttools does that for simple (pair & class) kerning. Matching contextual lookups though is very complicated task and unnecessary, given that we are moving the workflows to use variable .fea syntax.

The optimization you point out is indeed problematic though, if it's happening that way. I'm not sure.

0 replies

khaledhosny · 2026-03-31T12:16:59Z

khaledhosny
Mar 31, 2026
Collaborator

feaLib will certainly reuse implicit lookups whenever possible (and when it doesn't, that is usually considered a bug). Your two options is to either 1) not use implicit lookups 2) use variable scalars so that fotmake/ufo2ft cimpile the layout tables once, instead of one master at a time then merging the binary tables.

0 replies

devosb · 2026-03-31T17:41:38Z

devosb
Mar 31, 2026
Author

Thank you both for your very helpful comments. Where can I read about

variable .fea syntax
variable scalars

or are those two different names for the same concept? I see discussions about variable FEA syntax, but it is not clear to me what is implemented and therefore usable.

0 replies

khaledhosny · 2026-04-01T11:28:39Z

khaledhosny
Apr 1, 2026
Collaborator

They are the same thing. The syntax that feaLib currently supports is documented here: https://github.com/adobe-type-tools/afdko/pulls

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Problem building a variable font with contextual kerning #4077

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 8 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Problem building a variable font with contextual kerning #4077

Uh oh!

Uh oh!

devosb Mar 30, 2026

Replies: 8 comments

Uh oh!

behdad Mar 30, 2026 Maintainer

Uh oh!

devosb Mar 30, 2026 Author

Uh oh!

behdad Mar 30, 2026 Maintainer

Uh oh!

devosb Mar 30, 2026 Author

Uh oh!

behdad Mar 30, 2026 Maintainer

Uh oh!

khaledhosny Mar 31, 2026 Collaborator

Uh oh!

devosb Mar 31, 2026 Author

Uh oh!

khaledhosny Apr 1, 2026 Collaborator

devosb
Mar 30, 2026

behdad
Mar 30, 2026
Maintainer

devosb
Mar 30, 2026
Author

behdad
Mar 30, 2026
Maintainer

devosb
Mar 30, 2026
Author

behdad
Mar 30, 2026
Maintainer

khaledhosny
Mar 31, 2026
Collaborator

devosb
Mar 31, 2026
Author

khaledhosny
Apr 1, 2026
Collaborator