Variable font not exporting Light

Hi again, I’m exporting my variable font but it does not export the Light version. What am I doing wrong?

This might just be a caching issue. Does the issue persist after restarting your Mac?

Otherwise, try deleting all styles from Font Book and only installing the Light style. Does it still show up as “Regular”?

How do I install the Light only? Can I export all the fonts as separate font files? Right now I just have one .ttf file and it only allows me to install all fonts.

This is probably a font cache problem. Read this please: Eliminating Font Cache Problems | Glyphs

Okay I did the Shift restart for my Mac but still no difference when I try to install the .ttf. The Light is showing up as Regular. It’s probably due to me starting out the font as a Regular and switching it to the name Light later on.

If I export all weights as .otf then I am able to install the Light version. And it works properly in Photoshop.

Do you see the same problem in the app where you use the font?

Can you please send me the .glyphs file to support (at) (this website without ‘www’ or ‘forum’). I will have a look.

It seems that Apple’s font engine will use the ‘Typographic Subfamily Name’ (name table id 17, typically ‘Regular’ or ‘Roman’) for the instance that coincides with the variable font origin. I assume this is a bug in Apple’s software.

You have two options, a proper way and a hack. First the ‘proper’ way:

  1. Font Info > Exports > Regular instance > plus menu > Instance as Master
  2. Font Info > Masters: sort and review the new Regular master
  3. Font Info > Font > Custom Parameters: add a parameter called Variable Font Origin and choose Regular from its menu

… and export. The downside is that you need to manage a third master. The pro is that you have your variable font origin the way it was intended by the inventors of OTVAR.

Warning: the other option is a hack that will fix appearance in affected Mac apps, but may lead to problems elsewhere, or even in future versions of macOS. And it is a hack because you are trying to fix a bug in third-party software from within a font. To be fair, this has been much of the industry’s modus operandi with Microsoft’s horrible OpenType implementations in the past decades.

  1. Font Info > Exports: add a Variable Font Setting (through the plus menu in the bottom left)
  2. In the Variable Font Setting you created in the previous step, change the Name entry to what you want your variable font origin be called in the menu (Light in your case).

Again, this is not the intention of the Typographic Subfamily Name, and may confuse other implementations.

Why do you think it’s a bug? I think it’s just logical that the default instance (the outlines in the glyf table) should be reflected in the names ID1/2 respectively ID16/17 of the font. That way, in an environment that doesn’t support variable fonts and ignores the variation tables, the name and look of the font will still be correct.

OK, good point, then I must have been reading the spec wrong. Please correct me if I am wrong, but the spec does not clarify what ID 16/17 should be in an OTVAR, does it?

@Angele this means that the ‘hack’ is actually not a hack but the way to go :slight_smile:

I tried the hack but it’s still not showing the Light. I also sent support my files so hopefully, they’ll figure it out.

The spec for the fvar table only defines it the other way round, that the style name for the default instance should point to name ID 2 or 17:

The default instance of a font is that instance for which the coordinate value of each axis is the defaultValue specified in the corresponding variation axis record. An instance record is not required for the default instance, though an instance record can be provided. When enumerating named instances, the default instance should be enumerated even if there is no corresponding instance record. If an instance record is included for the default instance (that is, an instance record has coordinates set to default values), then the nameID value should be set to either 2 or 17, and the postScriptNameID value should be set to 6.

Note: Since an instance record for the default instance is not required, a variable font that has no instance records defined in the ‘fvar’ table (instanceCount is zero) still has one named instance.

@Angele just to make sure that you don’t see a bug that has already been fixed, which macOS version are you using?

This is a variable font where the ExtraLight is the default master in macOS 12.4. Other than that the SemiLight weight (weight 400) is shown at the top, each weight is listed in the correct order and only once.

Screenshot 2022-07-04 at 10.43.22

I haven’t updated in a while

The problem is not the order in which it is displaying my weights. It’s that it is showing as Regular instead of Light. I’m now having the same problem with the Italic version.

Also, how do I get both the Roman and the Regular to show up as one font family? Right now they are showing up separately when I install them.

Screenshot 2022-07-05 at 17.07.07

They need to have the same family name.

As for the order, Apple’s engine tries to be smart and orders the styles itself. You can be as expectable as possible with your naming, but it will do what it wants. Possible that menu ordering will change in an upcoming system version again.

1 Like

12.2.1 should be new enough. I know some bugs in older versions like 10.13, 10.14 …

1 Like

Okay, I got them all in the same family but the ‘light’ is still showing as ‘regular’ and now I have an error message saying I have 2 of the same font installed.

Screenshot 2022-07-06 at 11.35.06