Variable Font Instance set as Undefined

I know this problem might be related with how OpenType.js reads a variable font, but…

When I list a variable font (with its instances) in a webpage using opentype.js, it prints everything as expected except for one instance that is “Undefined”

MyFont_VF - undefined

As far as I know, this is because in the fvar the Regular version points to the subfamilyNameID=2 and is ignored. The other NameInstances point to a subfamilyName=259 or another.

Is there a way to overwrite this? I have already tried with “Regular” or “Normal” in the Typographic Style Names but doesn’t seem to change anything.




I have already tried adding a Name Table Entry to overwrite the ID=17 but it doesn’t seem to work. Any ideas?

Result:

{“name”:{“en”:“Thin”},“coordinates”:{“wght”:100}}
{“name”:{“en”:“Light”},“coordinates”:{“wght”:300}}
{“name”:{},“coordinates”:{“wght”:400}}
{“name”:{“en”:“Bold”},“coordinates”:{“wght”:700}}
{“name”:{“en”:“Black”},“coordinates”:{“wght”:900}}

I think I have found something…

If I change the instance name to anything else but Regular AND change the axis coordinate to 401 to trick and mismatch the Variable Font Origin, it DOES define that instance and another NamedInstance in the FVAR (via TTX).

Do you have a clue how can I do this without tricking the values?



Ugh. This reminds me of a hell of a bug search I conducted for this specific case, I think.

See my issue on the repo: fvar.instances returns empty name entry if nameID is 17 (preferredSubfamily) · Issue #687 · opentypejs/opentype.js · GitHub

Maybe you can re-open it and add your problem description.

1 Like

Can you show the STAT table of your font? Maybe it has something to do with the “elided fallback name” that is not present or interpreted incorrectly by opentype.js.

That looks like a bug in openType.js?

Sure.

The STAT is defined in Glyphs this way:

The STAT via TTX is this one:

The Named Instance in Glyphs is like this:

and FontDrop/FontGaulent are still refering to the subfamilyNameId=2

{“name”:{“en”:“Thin”},“coordinates”:{“wght”:100}}
{“name”:{“en”:“Light”},“coordinates”:{“wght”:300}}
{“name”:{},“coordinates”:{“wght”:400}}
{“name”:{“en”:“Bold”},“coordinates”:{“wght”:700}}
{“name”:{“en”:“Black”},“coordinates”:{“wght”:900}}

I think so… but shouldn’t the “Name Table Entry” values overwrite and point to the ID=17? Because even if I activate those values, the FVAR points to ID=2.

Or may be I am writing something wrong…

The name table entries do not change to what item the fvar table is pointing. But it shouldn’t make a difference if it points to ID2 or ID17

1 Like

Your STAT table looks fine. The bug must indeed lie at opentype.js.

My guess is that it doesn’t handle the “elided fallback name” mechanism correctly.

Your Regular style is at wght=400 and ital = 0, both locations have flags=2 set in STAT. That means the name of those axis values should not be used by applications to build the full font name. As no style name is left then, the name ID from ElidedFallbackNameID should be used, which also points to ID2 (Regular).

Thanks, Georg. I understand know is definitely an opentype.js bug.

Thanks Jens :smiley:

I will create an issue in the opentype.js github repository.

Please reference my issue, or re-open it. It sounds like it’s basically the same bug.

1 Like

Thanks Sebastian. I am checking it right now :smiley: