A no-lookup langsys is overriding the dflt langsys, so it changes font behavior if you drop it.

And for dropping dflt, yes, indeed, you need to either never drop it, or only drop it if it has no data whatsoever, including variations.

The problem here is that we want a latn dflt to attach some feature variation (Designspace rules) in a later step, but it is completely empty and therefore dropped when building the table with just the provided feature file. I assume there was no problem if the feature variations were written into the feature file.

The problem here is that we want a latn dflt to attach some feature variation (Designspace rules) in a later step, but it is completely empty and therefore dropped when building the table with just the provided feature file. I assume there was no problem if the feature variations were written into the feature file.

You can create it on demand. Isn't that complicated at all.

But my point stands that only empty dflt can be dropped, not any other empty langsys.

Right, so the fix would be to change

Right, so the fix would be to change

fonttools/Lib/fontTools/varLib/featureVars.py

Line 394 in e89d7db

if scriptRecord.Script.DefaultLangSys is None:

to just create it?

I think so.

The GSUB table builder seems to discard defined language systems when they have no lookups. This is a problem when we add feature variations in a later step, like we do when we compile a Designspace with rules.

@madig Have you tested if this issue also happens with fontc as well?

I have not, can do soon.

By the way, Harry and me were reading https://learn.microsoft.com/en-us/typography/opentype/spec/chapter2#scriptlist-table and wondered if a lazily-created "latn dflt" LangSys for feature variations should carry all features of "DFLT dflt"? Our reading of the spec says "no".

I don't think so either

By the way, Harry and me were reading https://learn.microsoft.com/en-us/typography/opentype/spec/chapter2#scriptlist-table and wondered if a lazily-created "latn dflt" LangSys for feature variations should carry all features of "DFLT dflt"? Our reading of the spec says "no".

Absolutely not. When the shaper chooses latn, it doesn't look at DFLT at all.

fontc (as of f187844659adae9f56003fb33ff4df93cd406190) seems to do the right thing, as in, I see a "latn dflt" entry for the rclt variation.