Hello team
I am unable to export font families with Fontcreator 15.0.0.3024, and have Windows 10 and other programs recognize the fonts as individual Style entries under a single font.
I have been working with Google’s Gemini to resolve the issue, and using MetaData2go, we have discovered that Fontcreator is writing the word “Regular” from Instances > Additional Naming Fields > Style Map Style Name to the font_subfamily-en-_us meta field. The Style Map Style Name can only be Regular, Bold, Italic, and Bold Italic. However, it is my understanding that programs use font_subfamily-en-_us to distinguish between all Typographic subfamilies. So it is my understanding that Fontcreator should be writing the Typographic Subfamily field to the font_subfamily-en-_us meta field.
Metadata2go output (note the appearance of the word “Regular” under subfamily):
**checksum** 042b2883a3a7b2a6ad1ff863c277b4b8
**file_name** WobblaGronk-Outline.ttf
**file_size** 83 kB
**file_type** TTF
**file_type_extension** ttf
**mime_type** application/font-ttf
**font_family-en-_us** Wobbla Gronk
**font_subfamily-en-_us** Regular
**font_subfamily_id-en-_us** Wobbla Gronk Outline: Version 1.005
**font_name-en-_us** Wobbla Gronk Outline
**name_table_version-en-_us** Version 1.005;August 25, 2025;
**post_script_font_name-en-_us** WobblaGronk-Outline
**description-en-_us** Wobbla Gronk
**preferred_subfamily-en-_us** Outline
**wws_family_name-en-_us** Wobbla Gronk
**wws_subfamily_name-en-_us** Outline
From Google Gemini, on reviewing my output from Metadata2go:
### **The Root Cause: Inconsistent Subfamily Naming**
The key issue is that the `font_subfamily-en-_us` field is inconsistent between the two files.
* **WobblaGronk-Regular.ttf**: `font_subfamily-en-_us` is correctly set to **`Regular`**.
* **WobblaGronk-Outline.ttf**: `font_subfamily-en-_us` is incorrectly set to **`Regular`** instead of `Outline`.
This is the reason Windows and Photoshop are hiding the `Outline` version. They are correctly reading both fonts as part of the `Wobbla Gronk` family, but because both have a subfamily name of `Regular`, the system only displays one of them by default.
So we humbly request that Typographic Subfamily be written to font_subfamily-en-_us.
Thank you,
Can you please send the font project to me, so I can look into this?
Thank you for sending the files. I noticed that in your font project the option “Generate the following naming fields on export” is unchecked.
This causes issues when exporting instances of a variable font, since each instance may require different values for those naming fields.
Please enable that option, re-export your fonts, and check if the problem is resolved. Let me know how it goes!
And if that doesn’t work, do let me know what you get and what you expect.
Alternatively you can keep “Generate the following naming fields on export” unchecked, but you need to change Style Map Family Name for the Outline instance from Wobbla Gronk to Wobbla Gronk Outline.
I ran some tests using FontDrop.info to review the metadata. I can now understand what the problem is, and I see multiple problems. This is all for exporting via ‘Statics from Instances’:
Additional Naming Fields > “Generate the Following naming fields on export” is UNCHECKED
- Fontcreator ignores Instances > General > Style Name. This field should probably be written to ID 2, font subfamily.
- Fontcreator does not write our entries for Typographic Family to ID 16, Preferred Family.
- Fontcreator does not write our entries for Typographic Subfamily Name to ID 17, Preferred Subfamily for the Regular instance
Additional Naming Fields > “Generate the Following naming fields on export” is CHECKED
- Fontcreator creates its own Font Family name, ID 1, which it builds out of the Font > General > Family Name and Instances > General > Style Name
- Fontcreator takes the Font > General > Family name and uses it as the Preferred Family, ID 16, but only for Instances that are not the Regular instance
- Fontcreator takes the Instances > General > Style Name and sets it as the Preferred Subfamily Name, ID 17, but only for Instances that are not the Regular instance.
Nothing about this behaviour is predictable, intuitive, or documented correctly in this master post: How to Group Widths and Weights as font styles inside one Typeface - #3 by outofstepfontco
I see from this analysis that it is absolutely necessary to check the “Generate the Following naming fields on export” for the first four fields under Instances > Additional Naming Fields. You execute a strategy where each Instance has a unique ID 1 Family Name, but share the ID 16 Preferred Family name.
I think the bigger issue is that we as Fontcreator users have not been left with any ability to write a common ID 1 Family name, unique ID 2 subfamily name, or ID 16 Typographic Family Name. Leaving the “Generate the Following naming fields on export” box unchecked writes only two metafields in a predictable and reliable manner: ID 1 Family name, and ID 17 Typographic Subfamily, but only for non-Regular instances.
I am reading more into your hybrid method and it’s clear that your strategy is the best one: Unique ID 1, common ID 16.
Older applications that rely primarily on **ID 1 (Font Family Name)** and **ID 2 (Font Subfamily Name)** for font organization include legacy versions of operating systems and office software.
These applications use a simple, two-level system to display fonts, which means they don't recognize the modern grouping provided by IDs 16 and 17.
What that tells me is that not checking “Generate the following naming fields on export” can only result in broken font families.
So we agree that in your case the Auto generation of the naming fields works correctly.
But it should also be possible to have “Generate the following naming fields on export” unchecked. Just change Style Map Family Name for the Outline instance from Wobbla Gronk to Wobbla Gronk Outline. Let me know if this works for you as well.
But it should also be possible to have “Generate the following naming fields on export” unchecked.
That’s the bug that we’re reporting. It is not possible. Fontcreator isn’t writing any data to ID 2 or ID 16. And re-importing the TTF into Fontcreator, Fontcreator doesn’t read or display any of the existing data from ID 16, ID 17, or Style Map Family Name in the Additional Naming table.
I can add them later in FontForge, but then I lose the DSIG table, since FontForge always wipes the DSIG table.
I will look into your solution when I have some time on the computer.
Thanks for your help,
It works just fine if you change Style Map Family Name for the Outline instance from Wobbla Gronk to Wobbla Gronk Outline.
We have an unofficial update that you should try:
https://www.high-logic.com/tmp/fontcreator/FontCreatorSetup15.0.0.3027-x64.exe
