Does Kern On know about substitutions in #ifdef VARIABLE blocks?

[Jeremy Tribby]

Syntax like this is supported in Glyphs for swapping Glyphs without using bracket layers in variable fonts. This way if you have a ton of them you can see the different glyphs in the font view, rather than tucked away in layers. To do it, you can put things like this in the rlig feature:

#ifdef VARIABLE
condition 140 < wght, 8 < opsz < 16;
sub dollar by dollar.micr;
condition 8 < opsz < 18;
sub yi-cy yi-cy by yi_yi-cy;
#endif

But kern On, on dollar.micr, for example, will have a warning icon, saying it can't be accessed via OpenType features. It's not OpenType, but it is valid Glyphs, and it doesn't seem like those inaccessible glyphs get auto kerning, so I have to wonder: is Kern On aware of them?

Here is some background on why there isn't a common feature syntax yet: https://github.com/googlefonts/glyphsLib/issues/800

[Tim Ahrens]

Kern On does not parse the feature code by itself. Instead, it asks Glyphs for a compiled version, and then browses the lookups. As it seems, by default, Glyphs doesn’t include the substitutions you are showing above, when I call the property GSFont.compositorFont. The question is, how can Kern On get hold of a compiled version of this code? Maybe Georg can help?

[Georg Seifert]

The “variable” code is not included in the temp font.
In this case, you could remove the “#ifdef Variable” … and remove the feature in all static instances. But that is not a good general solution.
I don’t think that I can add the variable substitutions in the compositor font.
One solution could be that you check the font but instead of automatically ignoring those glyphs, ask the user. Or do not check at all and trust the user to disable all unneeded glyphs?

[Tim Ahrens]

In this case, you could remove the “#ifdef Variable” … and remove the feature in all static instances.

You mean, Jeremy as the user, or would Kern On do this internally?

One solution could be that you check the font but instead of automatically ignoring those glyphs, ask the user. Or do not check at all and trust the user to disable all unneeded glyphs?

Not sure I understand. Who checks the font and what does “ignoring those glyphs” mean? Ask the user for what?

Note: This is about generating auto pairs via OT features. It is not about the question which glyphs need to be kerned.

[Tim Ahrens]

See https://kern-on.com/manual/#which-pairs-are-kerned

[Jeremy Tribby]

Can either the compositor font or Kern On support OT features from within the "Replace Feature" custom parameter on static instances? That is how I make sure these features from rlig make it into OTFs. This wouldn't solve the problem for people who have variable-only fonts but I would guess that is more of an exception

[mekkablue]

Workaround (Tim please correct me if I am wrong):

1. In Font Info > Font, add a Prefix with the substitutions as separated lookups:

lookup DOLLAR {
sub dollar by dollar.micr;
} DOLLAR;

lookup YIREPLACE {
sub yi-cy yi-cy by yi_yi-cy;
} YIREPLACE;

That way, the substitutions are visible to KernOn, I assume?



2. in the OpenType variations code, just call those lookups:

#ifdef VARIABLE
condition 140 < wght, 8 < opsz < 16; lookup DOLLAR;
condition 8 < opsz < 18; lookup YIREPLACE;
#endif

[Tim Ahrens]

That way, the substitutions are visible to KernOn, I assume?

Kern On sees whatever is inside GSFont.compositorFont. It does not look at the feature code at all.

[Jeremy Tribby]

Based on Georg's replies on the Glyphs forum is it fair to assume this is a long way off? It sounded like it would be complex for Georg to get this in the compositor font