Font names don't “translate” correctly from Windows to macOS

[bjornbm]

Describe the bug

On Windows, fonts weights names are compacted (for example, “ExtraLight”), while on macOS (12.6 Monterey) they are not (for example, “Extra Light”). This causes font misses in MS PowerPoint presentations moved between Window and macOS.

May be related to #206?

To Reproduce

Steps to reproduce the behavior:

1. Use Inter ExtraLight in PPT presentation on Windows
2. Open the PPT presentation on macOS

(Or vice versa)

Presumably applies to other “compound” weights as well, but I don't have access to windows and cannot easily check.

Expected behavior

Expected the correct font weight to be displayed, but it is not.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

• OS: macOS 12.6 Monterey, unknown Windows version.
• App that renders the font: MS PowerPoint
• Version of font: Extra Light. Version 3.019;git-0a5106e0b

[bjornbm]

FYI macOS Powerpoint font menu:

Windows Powerpoint font menu:

The “Inter Extra Light” is probably shown as a placeholder in this Windows font menu since there is such a font in the PPT presentation (created on a mac), but it is showing a place-holder font and not the correct one.

[rsms]

Would you mind trying the version 4 beta? https://github.com/rsms/inter/releases/tag/v4.0-beta7

[bjornbm]

Version 4.000;git-4fc901f on macOS did not help. At least not when opening a PPTX created with 3.19. Exactly same as above. I could ask my colleague to install the version 4 beta on Windows if you have reason to believe it may be fixed there.

[rsms]

I have no idea how to fix this. Help from someone who is an expert on this metadata would be very welcome!

[kenmcd]

Looks like the user has installed different versions on the different platforms. Appears that the MacOS version is the release from here (with spaces) and Windows version is from Google Fonts (no spaces). So it should work with the same versions installed on both platforms.

Note going forward... no-spaces is the "correct" way (according to GF and the recommendations in the OpenType specs). The FontBakery report in the above linked issue appears to have some errors in it (inconsistencies). Most likely this has been fixed. On my phone at the moment so I cannot check.

GF is always going to remove the spaces. So v4 should also for compatibility sake. Inter-4.0-beta7.(2022-10-24).release still has the same issues.

[bjornbm]

I thought my colleague downloaded and installed on Windows from here (not Google Fonts), but I can try to troubleshoot with him next week.

It is true that the GF version does seem to have no spaces (when viewed in Font Book.app). But with older versions of Inter I was suffering from rendering and printing problems, such as those reported in #156.

But it sounds like the way forward is clear from @kenmcd's comment? Would love an updated beta! :)

[kenmcd]

@bjornbm There are a few other things about PowerPoint which may complicate things if you attempt to embed the fonts in the PPT file, or a PDF (IIRC). PowerPoint on Windows will embed TTF fonts, but not OTF fonts. PowerPoint on Mac will not embed any fonts at all. So best not to try embedding and going back and forth between platforms. I suggest you both install the TTF (hinted) fonts and not try to embed while working on the presentation. When the presentation is finished, then you can use Windows to embed the TTF fonts in the final version.

An aside regarding the names... I checked and most fonts, and GF FB recommends, to have no space in the weight (e.g. ExtraLight, SemiBold, etc.) but they do have the space before Italic and for other "names" (e.g. Display) Windows uses the "style group" name in the font list, so you cannot see the Italic in the list. Italic is selected with the Italic button, not from the font list. So I would like to see Inter 4 have ExtraLight, SemiBold, ExtraBold (no spaces) in all font names.

[bjornbm]

Thanks @kenmcd on the notes regarding embedding. I also saw #525. Currently, we are not actually trying to embed fonts in our PPTX/DOCX files. Instead we both have Inter installed (but suffer from the problem in this issue). When we share docs with others, we generate PDFs with Inter embedded (seems to work fine).

What you say about the font names makes sense to me. If you can generate a new beta (@rsms?) I would be more than happy to test them.

[kenmcd]

What you say about the font names makes sense to me. ... I would be more than happy to test them.

These are v4-beta8 (TTF hinted) with modified names. Keep in mind you both need to have these same fonts. And you cannot use the original fonts at the same time. Or it will create quite a mess. I also moved the Display fonts into a separate typographic family (what you see on the Mac). That way the same families appear on both platforms.

Inter.4-beta8.with.Modified.Names.zip

Keep in mind that these are not official and that you may need to change fonts again in the future when the official v4 is released (or more betas) - and those may not be configured like this.

But these should get the job done for now so you can work on your presentation..

[bjornbm]

These fonts indeed resolved the problems we were having. The font names show without spaces now on mac, too, and “matches” properly the fonts of documents created on Windows. 😃

I needed to install the “Normal” family. Installing only the “Display” family did not work (which I guess is expected if it is a separate typographic family).

[rsms]

I think this is related to or even the same issue as #515

[rsms]

I've spent days on this by now and I can't figure out how to solve it. So unless someone who understands all this can help, I'll have to move on and leave it as is for version 4.0.

There are two challenges:

1. metadata for the variable fonts
2. metadata for static fonts (as is being discussed here)

@kenmcd how did you create "Inter.4-beta8.with.Modified.Names.zip"? Would be great to learn that so it can be integrated as a step in the makefile when compiling static fonts.

[edit] To be clear, according to TransType the style linking is all good when using the one family name "Inter":

But when I give the display fonts a family name of "Display" (and RIBBI style names like "Italic" and "Regular" instead of "Display Italic" and "Display"), TransType becomes unhappy and doesn't link styles properly:

[rsms]

b4d529e2d12c9451f09557e45409f808f33a35ee includes what I have so far. To build:

make -j static_otf

Here's an archive of OTFs: (same files you'd get from make static_otf) inter-static-otf-b4d529e2d12c9451f0955.zip

[kenmcd]

Saw your note above late yesterday just as I was heading out for the day. Love to help if I can. Going to work on this today. (so you can work on the other gazillion things in your ToDo list for the day)

[kenmcd]

@kenmcd how did you create "Inter.4-beta8.with.Modified.Names.zip"? Would be great to learn that so it can be integrated as a step in the makefile when compiling static fonts.

[edit] To be clear, according to TransType the style linking is all good when using the one family name "Inter":

But when I give the display fonts a family name of "Display" (and RIBBI style names like "Italic" and "Regular" instead of "Display Italic" and "Display"), TransType becomes unhappy and doesn't link styles properly:

OK. I can see what the issue is, and how to fix it. Easy to fix in FontLab, but it could not read the fontinfo.plist file from the Glyphs package. Recently I set-up a VM with macOS Ventura and Glyphs app. Have not really worked with it until now (slowly finding my way around today). But I can now see how to do this in Glyphs (which is kinda convoluted compared to FL). Should be able to finish this today, and output some static fonts to test. Note: I am going to remove the spaces in SemiBold, etc. like I did above. (unless you have an issue with this) I think when I am done the only thing which will change is the two fontinfo.plist files.

Note going forward - you may want to consider using UFO sources rather than the Glyphs package. Would make it easier, and more likely, for other non-Mac users to contribute.

[rsms]

@kenmcd: Love to help if I can. Going to work on this today.

Amazing!

[rsms]

@kenmcd

Recently I set-up a VM with macOS Ventura and Glyphs app. Have not really worked with it until now (slowly finding my way around today). But I can now see how to do this in Glyphs (which is kinda convoluted compared to FL).

Keep in mind that the build setup does some metadata processing on the UFOs generated from the Glyphs sources. See the Makefile. For example, misc/tools/postprocess-designspace.py is run whenever the glyphs data changes and patches the designspace and master UFOs.

Note: I am going to remove the spaces in SemiBold, etc. like I did above. (unless you have an issue with this)

Is this really necessary? It seems a little "computer over human" to remove the spaces. I think I've heard that some older Microsoft software has issues with styles with spaces in their names, is that why you would prefer to strip spaces from the style names? (Also, does italic styles get all or just some spaces stripped? E.g. "SemiBoldItalic" vs "SemiBold Italic")

Note going forward - you may want to consider using UFO sources rather than the Glyphs package.

I'm afraid that's a no. Inter used to be authored in RoboFont as UFO sources and it took quite some effort to port to glyphs. Maybe Glyphs' UFO interop has improved by now, but back then working with UFO sources was definitely a second-class experience. I can recall exactly the issues I had, but I think it was quite slow and some Glyphs features didn't work.

Would make it easier, and more likely, for other non-Mac users to contribute.

I totally get that and it's a bummer Glyphs only exists for macOS, but I find the experience superior to both RoboFont and FontLab (I've only "trialed" FL, haven't actually worked in it.) The Glyphs team is also really incredible, with fantastic customer support and quick turnaround for bugs etc.

[rsms]

@kenmcd Ideally we can make the changes needed to the UFOs during the build process, leaving the Glyphs sources as they are. Any metadata from Glyphs is converted to UFO before compilation, so anything can be altered at that stage. Now, some things we might eventually want to "permanently" change in the Glyphs source, but it might be a good place to start by setting/altering metadata at the UFO stage "to get going." This would also remove a lot of "busy work" for you by not having to use Glyphs in a macOS vm.

[kenmcd]

Well I am kinda stuck. Got the names all entered for the Roman font. Now trying to export the Roman fonts. First I got an error regarding two 0357 characters. Disabling export of either one resulted in different error messages. So I deleted one and refreshed an affected feature class. That allowed the export to run. But it only exported four fonts. Chokes on the Inter-Medium and displays an error message.

Error message is: Problem compiling "GPOS" table Subtable OverFlow in lookup: 7 type: MarkToBaseAttachment

Now since the duplicate glyph I deleted is a mark this new error could be the result of that. Dunno. Would expect it to not work at all - but four fonts did export. My lack of familiarity with Glyphs is not good for troubleshooting.

Perhaps you can update the source to fix the duplicate properly. (the errors were related to the duplicates, and the changed glyph name in feature classes, etc.) Then I can just add back my current fontinfo.plist file, and try exporting again. (not real familiar with what all is in that file, but your changes to the glyphs and feature classes are probably there - so I may try to just merge my name changes)

Meanwhile, I am going to make the name changes to the Italic, and try exporting that.

[rsms]

@kenmcd

First I got an error regarding two 0357 characters. ... Perhaps you can update the source to fix the duplicate properly.

Sorry. Just fixed that. (Do a git pull)

Problem compiling "GPOS" table Subtable OverFlow in lookup: 7 type: MarkToBaseAttachment

Long standing issue with Glyphs built-in export. I don't export fonts from Glyphs, instead I use fontmake via the Make setup. Ie. in a terminal, run make -j build/fonts/var/Inter.var.ttf to build the Roman variable font or make -j build/fonts/static/Inter-DisplayMedium.otf to build "Inter Display Medium". You can also build a bunch of fonts in one go with make -j static_otf or make -j var

As mentioned earlier, I suggest trying to make the fixes on the UFO level instead of the Glyphs level.

What I recommend you try is this workflow:

1. Generate editable UFOs: make -j editable-ufos
2. Copy the editable UFOs in place for make to find them and use them to compile fonts: rm -rf build/ufo && cp -R build/ufo-editable build/ufo
3. Edit the UFOs and designspace files in build/ufo/ whatever way you please (font editor or text editor.)
4. Build fonts with make -j static_ttf var (this will build all static fonts and all variable fonts into build/fonts/)
5. Test the result
6. Repeat step 3 and onwards until satisfied

Once satisfied, document the changes (you can compare the original UFOs in build/ufo-editable to your edits in build/ufo) and then I (or we, if you want) can integrate them "permanently" into the build system and/or the Glyphs source.

[kenmcd]

Keep in mind that the build setup does some metadata processing on the UFOs generated from the Glyphs sources. See the Makefile. For example, misc/tools/postprocess-designspace.py is run whenever the glyphs data changes and patches the designspace and master UFOs.

Yes, I notice this today when I updated from GitHub. But I think all of it can be done in the Glyphs source. At least for the statics. There may be some post-processing required for the variable. If I can get the statics to export we can see if it works with just the Glyphs source. Think it will.

Is this really necessary? It seems a little "computer over human" to remove the spaces. I think I've heard that some older Microsoft software has issues with styles with spaces in their names, is that why you would prefer to strip spaces from the style names? (Also, does italic styles get all or just some spaces stripped? E.g. "SemiBoldItalic" vs "SemiBold Italic")

Google Fonts requires it - e.g. SemiBold Noto Sans SemiBold, Apple uses both: Semibold and SFDisplay-SemiBold, etc. Adobe uses both: Source Serif 4 Semibold, Minion 3 SemiBold Microsoft: Bahnschrift SemiBold, Segoe UI Semibold, Cascadia Code SemiBold Monotype: Helvetica Now Display ExtraBold

IBM Plex Sans SemiBold Literata SemiBold Recursive Sans Linear Static SemiBold Spectral SemiBold STIX Two Text SemiBold

Appears that no-space is the most common. It does look weird to me when the space is there. Very few fonts have the spaces now.

Noticed today that Glyphs uses "SemiBold" in the Weight Class dropdown select list. All weight with no spaces and camelcase.

So, yes, I would prefer it, and think most users would too. And I think it would be good to match GF (or more user issues just like this one). But, obviously it is ultimately up to you.

[kenmcd]

I understand and agree regarding the limitations of UFO. Same thing happens with FL to UFO - some stuff may be missing.

What I recommend you try is this workflow:

1. Generate editable UFOs: `make -j editable-ufos`

2. Copy the editable UFOs in place for make to find them and use them to compile fonts: `rm -rf build/ufo && cp -R build/ufo-editable build/ufo`

3. Edit the UFOs and designspace files in `build/ufo/` whatever way you please (font editor or text editor.)

4. Build fonts with `make -j static_ttf var` (this will build all static fonts and all variable fonts into `build/fonts/`)

5. Test the result

6. Repeat step 3 and onwards until satisfied

Once satisfied, document the changes (you can compare the original UFOs in build/ufo-editable to your edits in build/ufo) and then I (or we, if you want) can integrate them "permanently" into the build system and/or the Glyphs source.

OK. Will try this over the next few days. Was hoping that the latest FL8 solved all the Glyphs round-trip issues - but no such luck. I really would like to get to the point where I can contribute normal PRs without any issues. But with the prevalence of Glyphs sources (and related tools) in most of the Google Fonts and related repos it is difficult.

[kenmcd]

Did a test export on the Italic and it also failed. Perhaps I should wait until the sources are at a point more ready to test. I realize it is a work-in-progress and that it is quite normal to break stuff as you are working. So I can wait until it is convenient for you. Just let me know.

[kenmcd]

@rsms I have not been successful in exporting the fonts on Windows. Cygwin does enable various linux file commands, but I still had too many errors which I did not know how to fix.

So let me show you what I was attempting to do in Glyphs. When editing the names in FontLab or TransType I am directly editing the Name 01, 02, 16, 17 fields. So I figured that is what I would also do in Glyphs. Glyphs allows you to add the Style Group Name & Style (01 & 02), and the Typographic Name & Style (16 & 17). But because of other issues, I could not get it to export all the fonts (it exported only three and then died on Medium with a GPOS error). This is what that looked like for the InterDisplay-Regular. (note: this example is just one font I changed the latest files to make this screenshot).

So I had added those fields to all the Display fonts. And deleted the WWS names (which are not needed). But I could not export the fonts and test to see if that works. I expect it would work as I did all the style-linking manually. (just like in TransType or FontLab).

The Cormorant font does this differently (and perhaps more simply). I noticed that the Cormorant font family exports five different families from one Cormorant.glyphs file. And the Typographic Families match-up with the Style group families - like I did in the fonts above. So I took a closer look. He adds just the "Localized Family Names" field. Like this:

It appears to affect affect both the Typographic Family (16) and the Font Family (01, style group) - so the fonts are named like the examples I made above, where the families are the same on Mac and Win. The .glyphs files are here: https://github.com/CatharsisFonts/Cormorant/tree/master/sources

I think it is best to do this in the Glyphs sources rather than in some after processing script.

I realized I can do this in Glyphs and simply send or PR just the fontinfo.plist file from the package. So I can do that if you would like.

---

Side note: I am concerned that there are some issues in the sources which are not found during the current build process (like the duplicate glyphs). This may cause other issues, and may be why I cannot export the fonts successfully. I recommend you test exporting directly from Glyphs.

[rsms]

e12027c4c107731fd33823578fd7ca5107d38b8f removes "Display" named-instances from variable font

A lot of software gets confused when there are named instances that differ only by opsz. This change removes all "Display" instances from the fvar table and makes opsz=32 the default, so that software without automatic opsz-to-size mapping displays the "Display" styles instead of the text styles by default.

This is the same approach taken by Apple San Francisco Pro.

It works correctly in macOS 10 and with freetype/hb-based tools like Figma.

@bjornbm @kenmcd Would you please test this (below) build and confirm if it works for you? ~Inter-4.0-e12027c4c1.zip~ v4.0-beta9 + bd33b4148b

[rsms]

(Keeping it open until we have confirmation of success on Windows)

[kenmcd]

@kenmcd Would you please test this (below) build and confirm if it works for you? Inter-4.0-e12027c4c1.zip

No. Too late here to deal with this today. (I am in same time zone as you). Will do PR tomorrow with the method I mentioned above. That should fix the statics.

[rsms]

Testing on a Windows 10 machine and v4.0-beta9 + bd33b4148b seems to be working as expected.

The static font files behave correctly in WordPad:

However the variable fonts render very poorly and have "28pt" added to their style names: (by Windows; there's no name table string in the font for these)

[kenmcd]

OK, just got the latest from the repo to get started on this. Going to focus on the statics first.

I did see the odd stuff in the VF yesterday, but not sure where it is coming from. Will look at that when I open the .glyphs files. But it could be coming from something in the build process. Will have look at that later today after the statics are fixed.

Note: when I open the .glyphs files it always gives me a message that they were created with an older version of Glyphs. I think I have the latest version - v3.1.1 I will take a screenshot today when I open the files. It may be an issue because it also mentions some changes it wants to make to the files (for the new version). That could affect other things in the fontinfo.plist files that I really do not want to touch (and should not). Could be a problem.

Anyway should have a PR to fix the statics for you to test this morning. If that "Cormorant" method does not work, I can then do the other method where I added both the Typographic fields directly, and see if that works. Need to test exporting directly from Glyphs first to make sure that fontmake is not the cause.

[rsms]

OK, just got the latest from the repo to get started on this. Going to focus on the statics first.

Sounds good. Ignore the VF for now. Not sure if Windows supports VFs anyways.

Note: when I open the .glyphs files it always gives me a message that they were created with an older version of Glyphs. I think I have the latest version - v3.1.1 I will take a screenshot today when I open the files. It may be an issue because it also mentions some changes it want to make to the files. That could affect other things in the fontinfo.plist that I really do not want to touch (and should not). Could be a problem.

3.1.2 seems to be the latest version.

AFAIK this has no impact on the editing. All you'll see related to this in your diffs is the .appVersion in fontinfo.plist. You can either upgrade Glyphs or just ignore that notification (you can check a checkbox to silence it.)

Anyway should have a PR to fix the statics for you to test this morning. If that "Cormorant" method does not work, I can then do the other method where I added both the Typographic fields directly, and see if that works. Need to test exporting directly from Glyphs first to make sure that fontmake is not the cause.

Awesome!

[kenmcd]

Ahhh ... so I have the older version. Guess I mis-remembered the error message.

[bjornbm]

Hi, sorry to be late with the testing @rsms. I'm not sure if it is still relevant or superseded by @kenmcd's results. But, here is what I see for inter.ttc from https://d.rsms.me/tmp/Inter-4.0-bd33b4148b.zip:

As you can see, the style is Semi Bold, while I think the conclusion previously was that it needs to be SemiBold (or at least the same on macOS and Windows?). Same for Extra Light versus ExtraLight. See https://github.com/rsms/inter/issues/519#issuecomment-1499612561.

[rsms]

@bjornbm Could you please try v4.0-beta9d? It uses style names without spaces for both static and variable fonts.

Screenshot of Apple Font Book:

[bjornbm]

Looks right to me! And my/our old docs appear to render correctly with beta9d. (I installed only Inter.ttc)

[kenmcd]

Better. But still issues with the Display Thin and Display ExtraLight fonts.

Specifically:

Thin and Thin Italic - style group (name ID1) is Inter Display (this conflicts with the primary Inter Display R/I/B/BI style group of the same name) Style group should be Inter Display Thin And they already correctly marked as Regular & Regular Italic of that style group.

ExtraLight and ExtraLight Italic - style group is Inter Display And it is set-up as the "Bold" of the Regular styles Style group should be Inter Display ExtraLight And they should be marked as Regular & Regular Italic of this style group.

These will cause issues on Windows and in any application which uses/understands the style-linking (even on Mac).

[rsms]

@kenmcd what tables are you looking at to check this?

[rsms]

I've set explicit WWS names in e11ab3a9a7e1d2a88e191459587a897e6f649b6b according to https://glyphsapp.com/learn/naming#g-wws-names-name-ids-21-and-22 — see it that helped: https://d.rsms.me/tmp/Inter-4.0-063ece5e2f.zip

[kenmcd]

Adding WWS names does not fix the issue. That just gives some apps another way to look at it that may work for that particular app. Which is why I removed them in the PR (just makes things worse).

@kenmcd what tables are you looking at to check this?

The name table nameID 1 and nameID 2 nameID 1 is Font Family Name (or style group)

These are not correct in Inter Display Light, Light Italic, ExtraLight, and ExtraLight Italic. In all four the nameID 1 is Inter Display That is the same as the Inter Display Regular, Italic, Bold, and Bold Italic fonts (in the correct Inter Display style group). So there is a conflict in any app which uses the style groups.

Cormorant added the default Localized Font Name field to each of the "Exports" - and that seems to work for them creating multiple font families from one .glyphs file. So I assumed that would work. I guess you have not tried the PR I submitted.

The alternate method I mentioned above adds fields for name IDs 1, 2, 16, 17. In FontLab or TransType we are entering the names directly into those fields. This enables that same direct access in Glyphs. So that should also work in Glyphs.

[rsms]

The name table nameID 1 and nameID 2 nameID 1 is Font Family Name (or style group)

I see. Wouldn't setting the family to e.g. "Inter Display Thin" cause the "family" to be registered as "Inter Display Thin" rather than "Inter Display" in software like macOS?

There are the current name entries for a few select static .ttf font files:

Inter-DisplayThin.ttf
   1 familyName        Inter Display
   2 subfamilyName     Thin
   3 fontId            4.000;git-063ece5e2;RSMS;InterDisplay-Thin
   4 fullName          Inter Display Thin
   6 postscriptName    InterDisplay-Thin
  16 typoFamilyName    Inter Display
  17 typoSubfamilyName Thin
  21 wwsFamilyName     Inter Display
  22 wwsSubfamilyName  Thin

Inter-DisplayThinItalic.ttf
   1 familyName        Inter Display
   2 subfamilyName     Thin Italic
   3 fontId            4.000;git-063ece5e2;RSMS;InterDisplay-ThinItalic
   4 fullName          Inter Display Thin Italic
   6 postscriptName    InterDisplay-ThinItalic
  16 typoFamilyName    Inter Display
  17 typoSubfamilyName Thin Italic
  21 wwsFamilyName     Inter Display
  22 wwsSubfamilyName  Thin Italic

Inter-Thin.ttf
   1 familyName        Inter Thin
   2 subfamilyName     Regular
   3 fontId            4.000;git-063ece5e2;RSMS;Inter-Thin
   4 fullName          Inter Thin
   6 postscriptName    Inter-Thin
  16 typoFamilyName    Inter
  17 typoSubfamilyName Thin
  21 wwsFamilyName     Inter
  22 wwsSubfamilyName  Thin

Inter-ThinItalic.ttf
   1 familyName        Inter Thin
   2 subfamilyName     Italic
   3 fontId            4.000;git-063ece5e2;RSMS;Inter-ThinItalic
   4 fullName          Inter Thin Italic
   6 postscriptName    Inter-ThinItalic
  16 typoFamilyName    Inter
  17 typoSubfamilyName Thin Italic
  21 wwsFamilyName     Inter
  22 wwsSubfamilyName  Thin Italic

Cormorant added the default Localized Font Name field to each of the "Exports" - and that seems to work for them creating multiple font families from one .glyphs file. So I assumed that would work.

I saw your screenshots in your earlier comment and I'm trying to figure out how it impacts "advanced" software that handles more than just RIBBI.

name entries when I build without "Localized Family Names":

 1 familyName         Inter Display
 2 subfamilyName      Light
 4 fullName           Inter Display Light
 6 postscriptName     InterDisplay-Light
16 typoFamilyName     Inter Display
17 typoSubfamilyName  Light
21 wwsFamilyName      Inter Display
22 wwsSubfamilyName   Light

name entries when I build with "Localized Family Names" set to "Inter Display": (no change)

 1 familyName         Inter Display
 2 subfamilyName      Light
 4 fullName           Inter Display Light
 6 postscriptName     InterDisplay-Light
16 typoFamilyName     Inter Display
17 typoSubfamilyName  Light
21 wwsFamilyName      Inter Display
22 wwsSubfamilyName   Light

name entries when I build with "Localized Family Names" set to "Inter Display Light":

 1 familyName         Inter Display Light
 2 subfamilyName      Regular
 4 fullName           Inter Display Light
 6 postscriptName     InterDisplay-Light
16 typoFamilyName     Inter Display
17 typoSubfamilyName  Light
21 wwsFamilyName      Inter Display
22 wwsSubfamilyName   Light

Notice how there's no effect setting "Localized Family Names" to "Inter Display".

Setting "Localized Family Names" to "Inter Display Light" is not what we want I think. i.e "Light" is not part of the family; we would get a bunch of separate families with just "Regular" and "Italic" styles each.

I guess you have not tried the PR I submitted.

I did, but the build is failing. I left a comment: https://github.com/rsms/inter/pull/575#issuecomment-1572542496

[rsms]

Here's a build with "Localized Family Names" set to "Inter Display" for all static display fonts: https://d.rsms.me/tmp/Inter-4.0-036a0373b2.zip

@bjornbm does this seem to work correctly for you?

@kenmcd I think the result here is the same as what you're working on in the PR #575, right? i.e. for Inter Display Thin, the name table looks like this:

 1 familyName         Inter Display
 2 subfamilyName      Light
 4 fullName           Inter Display Light
 6 postscriptName     InterDisplay-Light
16 typoFamilyName     Inter Display
17 typoSubfamilyName  Light
21 wwsFamilyName      Inter Display
22 wwsSubfamilyName   Light

[kenmcd]

Don't even have to look - that is not going to work.

For Inter Display Thin nameID 1 should be: Inter Display Thin nameID 2 should be: Regular For Inter Display Thin Italic nameID 1 should be: Inter Display Thin nameID 2 should be: Italic Then those two fonts are in that style group.

nameID 2 should only be: Regular or Italic or Bold or Bold Italic

The default Localized Font Name appears to end up in the nameID 1 field - so for the 2 Thin fonts that should be Inter Display Thin Both masters have to match the style group (nameID 1).

The Typographic Family and Style (nameID 16 and nameID 17) appear to be coming from other fields.

I think I know how it works (Glyphs), but cannot test the results of my changes (and apparently you cannot either).

Adding all four fields should work for sure - and in that case we know exactly where each field's data is coming from.

Perhaps tomorrow I should make you a spreadsheet with all the fields as they should be. That way it is easier to get the whole picture.

[rsms]

Perhaps tomorrow I should make you a spreadsheet with all the fields as they should be. That way it is easier to get the whole picture.

That would be fantastic!

It's tricky to set all of this up since the variable font sources from the same stuff and we need to keep that working, too.

I don't have a PowerPoint license (nor Word license) but this is what I see in WordPad and Windows 10 settings when I install the build linked to above:

Windows 10 settings correctly lists all styles, in the expected order:

RIBBI works in WordPad (⌃B and ⌃I links to the expected italic and bold styles) but here I see there are issues with Inter Display, still: (styles of Inter Display are missing in list)

[rsms]

I tried building the fonts with the following metadata, setting name ID 1 to "FAMILY STYLE" and name ID 2 to either "Regular" or "Italic". This does not work at all (which is what I expected; just get a bunch of families on macOS)

 1 familyName       Inter Display Thin
 2 subfamilyName    Regular
 4 fullName         Inter Display Thin Regular
 6 postscriptName   InterDisplay-Thin
21 wwsFamilyName    Inter Display
22 wwsSubfamilyName Thin

I suspect that macOS might use ID 16 & 17, so going to try and add those

[edit] Yeah, that did it for macOS:

[rsms]

Okay, I think that did it. Works as expected in Apple TextEdit on macOS and Microsoft WordPad on Windows 10

This is what the name table of InterDisplay-Thin.ttf looks like now:

 1 familyName        Inter Display Thin
 2 subfamilyName     Regular
 4 fullName          Inter Display Thin
 6 postscriptName    InterDisplay-Thin
16 typoFamilyName    Inter Display
17 typoSubfamilyName Thin
21 wwsFamilyName     Inter Display
22 wwsSubfamilyName  Thin

Here's a new build to test: https://d.rsms.me/tmp/Inter-4.0-d88ab4204a.zip (cc @bjornbm)

[kenmcd]

The good news: Display Thin and Display ExtraLight are now good! The bad news: Display ExtraBold and Display Black are now messed-up. But just the two Roman fonts - the Italics are fine.

Inter Display ExtraBold nameID 1 is Inter Display Medium and should be Inter Display ExtraBold nameID 2 is Bold and should be Regular This error has the effect of making ExtraBold the "Bold" of the Medium, rather than the "Regular" of the ExtraBold.

Inter Display Black nameID 1 is Inter Display SemiBold and should be Inter Display Black nameID 2 is Bold and should be Regular This error has the effect of making Black the "Bold" of the SemiBold, rather than the "Regular" of the Black.

Looks like the Bold and Italic flags are ending up correct - not sure how.

Almost there!

[rsms]

Nice catch!

Removing these style links from ExtraBold and Black causes the "correct" UFO fontinfo to be generated by glyphsLib:

New build with that removed: https://d.rsms.me/tmp/Inter-4.0-8b4135611f.zip

[kenmcd]

The good news:

• all the TTF fonts in the TTC are now good! Perfect.
• all the fonts in the extras/ttf folder are also good.
• all the .woff2 fonts look good.

The bad news:

• the Display fonts in the extras/otf folder are waaaay off.
• Looks like a bomb went off.
• Five different Typographic families (nameID 16) - should be one
• 18 different style groups (nameID 01) - should be 8

????

[rsms]

• all the TTF fonts in the TTC are now good! Perfect.

Great!

• all the fonts in the extras/ttf folder are also good.

The .ttc is created from these, so they are practically identical

• all the .woff2 fonts look good.

The bad news:

• the Display fonts in the extras/otf folder are waaaay off.
• Looks like a bomb went off.

Ha ha ha...

• Five different Typographic families (nameID 16) - should be one
• 18 different style groups (nameID 01) - should be 8

Weird, I see different data:

FILE                              │ ID 16         │ ID 17
──────────────────────────────────┼───────────────┼──────────────────
Inter-Black.otf                   │ Inter         │ Black
Inter-BlackItalic.otf             │ Inter         │ Black Italic
Inter-ExtraBold.otf               │ Inter         │ ExtraBold
Inter-ExtraBoldItalic.otf         │ Inter         │ ExtraBold Italic
Inter-ExtraLight.otf              │ Inter         │ ExtraLight
Inter-ExtraLightItalic.otf        │ Inter         │ ExtraLight Italic
Inter-Light.otf                   │ Inter         │ Light
Inter-LightItalic.otf             │ Inter         │ Light Italic
Inter-Medium.otf                  │ Inter         │ Medium
Inter-MediumItalic.otf            │ Inter         │ Medium Italic
Inter-SemiBold.otf                │ Inter         │ SemiBold
Inter-SemiBoldItalic.otf          │ Inter         │ SemiBold Italic
Inter-Thin.otf                    │ Inter         │ Thin
Inter-ThinItalic.otf              │ Inter         │ Thin Italic
InterDisplay-Black.otf            │ Inter Display │ Black
InterDisplay-BlackItalic.otf      │ Inter Display │ Black Italic
InterDisplay-ExtraBold.otf        │ Inter Display │ ExtraBold
InterDisplay-ExtraBoldItalic.otf  │ Inter Display │ ExtraBold Italic
InterDisplay-ExtraLight.otf       │ Inter Display │ ExtraLight
InterDisplay-ExtraLightItalic.otf │ Inter Display │ ExtraLight Italic
InterDisplay-Light.otf            │ Inter Display │ Light
InterDisplay-LightItalic.otf      │ Inter Display │ Light Italic
InterDisplay-Medium.otf           │ Inter Display │ Medium
InterDisplay-MediumItalic.otf     │ Inter Display │ Medium Italic
InterDisplay-SemiBold.otf         │ Inter Display │ SemiBold
InterDisplay-SemiBoldItalic.otf   │ Inter Display │ SemiBold Italic
InterDisplay-Thin.otf             │ Inter Display │ Thin
InterDisplay-ThinItalic.otf       │ Inter Display │ Thin Italic

Any chance you were looking at an older version? I'm looking at the last build (posted earlier) Inter-4.0-8b4135611f.zip

BTW, the only production difference between TTF and OTF files is how I invoke fontmake:

fontmake -u InterXXX.ufo -o ttf --output-path InterXXX.ttf
fontmake -u InterXXX.ufo -o otf --output-path InterXXX.otf

[kenmcd]

Hmmmm... not what I am seeing. Double-checked that I had the correct ZIP. Even downloaded the ZIP again from your link above. Checked those fonts again.

Lots of weird stuff. First, no nameID 16 & 17 in the four Inter Display R/I/B/BI fonts. Same in the Inter R/I/B/BI fonts. This is common (but not always a good idea, see below).

I reviewed the fonts again in OTM Lite and TTX (both make no changes). For example... Here is the name table from ttx for InterDisplay-BlackItalic.otf

  <name>
    <namerecord nameID="4" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Inter Display Black Italic
    </namerecord>
    <namerecord nameID="6" platformID="1" platEncID="0" langID="0x0" unicode="True">
      InterDisplay-BlackItalic
    </namerecord>
    <namerecord nameID="0" platformID="3" platEncID="1" langID="0x409">
      Copyright 2016 The Inter Project Authors
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Inter Display Black Italic
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Italic
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
      4.000;git-9e6dd3d7f;RSMS;InterDisplay-BlackItalic
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
      Inter Display Black Italic
    </namerecord>
    <namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
      Version 4.000;git-9e6dd3d7f
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
      InterDisplay-BlackItalic
    </namerecord>
    <namerecord nameID="7" platformID="3" platEncID="1" langID="0x409">
      Inter UI and Inter is a trademark of rsms.
    </namerecord>
    <namerecord nameID="8" platformID="3" platEncID="1" langID="0x409">
      rsms
    </namerecord>
    <namerecord nameID="9" platformID="3" platEncID="1" langID="0x409">
      Rasmus Andersson
    </namerecord>
    <namerecord nameID="11" platformID="3" platEncID="1" langID="0x409">
      https://rsms.me/
    </namerecord>
    <namerecord nameID="12" platformID="3" platEncID="1" langID="0x409">
      https://rsms.me/
    </namerecord>
    <namerecord nameID="13" platformID="3" platEncID="1" langID="0x409">
      This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
    </namerecord>
    <namerecord nameID="14" platformID="3" platEncID="1" langID="0x409">
      http://scripts.sil.org/OFL
    </namerecord>
    <namerecord nameID="16" platformID="3" platEncID="1" langID="0x409">
      Inter Display
    </namerecord>
    <namerecord nameID="17" platformID="3" platEncID="1" langID="0x409">
      Black Italic
    </namerecord>
    <namerecord nameID="21" platformID="3" platEncID="1" langID="0x409">
      Inter Display
    </namerecord>
    <namerecord nameID="22" platformID="3" platEncID="1" langID="0x409">
      Black Italic
    </namerecord>
    <namerecord nameID="256" platformID="3" platEncID="1" langID="0x409">
      Open digits
    </namerecord>
    <namerecord nameID="257" platformID="3" platEncID="1" langID="0x409">
      Disambiguation
    </namerecord>
    <namerecord nameID="258" platformID="3" platEncID="1" langID="0x409">
      Disambiguation (no slashed zero)
    </namerecord>
    <namerecord nameID="259" platformID="3" platEncID="1" langID="0x409">
      Alternate one
    </namerecord>
    <namerecord nameID="260" platformID="3" platEncID="1" langID="0x409">
      Open four
    </namerecord>
    <namerecord nameID="261" platformID="3" platEncID="1" langID="0x409">
      Open six
    </namerecord>
    <namerecord nameID="262" platformID="3" platEncID="1" langID="0x409">
      Open nine
    </namerecord>
    <namerecord nameID="263" platformID="3" platEncID="1" langID="0x409">
      Lower-case L with tail
    </namerecord>
    <namerecord nameID="264" platformID="3" platEncID="1" langID="0x409">
      Simplified u
    </namerecord>
    <namerecord nameID="265" platformID="3" platEncID="1" langID="0x409">
      Alternate German double s
    </namerecord>
    <namerecord nameID="266" platformID="3" platEncID="1" langID="0x409">
      Upper-case i with serif
    </namerecord>
    <namerecord nameID="267" platformID="3" platEncID="1" langID="0x409">
      Flat-top three
    </namerecord>
    <namerecord nameID="268" platformID="3" platEncID="1" langID="0x409">
      Capital G with spur
    </namerecord>
    <namerecord nameID="269" platformID="3" platEncID="1" langID="0x409">
      Compact f
    </namerecord>
    <namerecord nameID="270" platformID="3" platEncID="1" langID="0x409">
      Compact t
    </namerecord>
    <namerecord nameID="271" platformID="3" platEncID="1" langID="0x409">
      Round quotes &amp; commas
    </namerecord>
  </name>

Note: nameID="1" is Inter Display Black Italic That should be Inter Display Black to put it in the same style group as the Display Black Regular. All 18 of the nameID="1" fields are different Oddly, they are all the same as Full Font Name (nameID=4).

Another example... InterDisplay-Bold.otf nameID 1 is Inter Display Bold (should be Inter Display) nameID 2 is Regular (should be Bold)

Could go on and on, but just more of the same - nameID 1 & 2 are not right.

Note: Regarding me seeing five Typographic Families... It appears that TransType is confused by the missing nameID 16 in the four Display R/I/B/BI fonts and picked-up the nameID 1 family names. So Inter Display plus those four families = the five I saw. Normally nameID 1 in the basic R/I/B/BI group and nameID 16 should be the same. They are not, which threw off both me and TransType. I know it is common to leave 16&17 out of the basic R/I/B/BI fonts, but this is why I put them in. And is a must if you have two or more R/I/B/BI groups.

But, I do still see 18 different nameID 1 upon close re-examination. So the style-linking/style groups are very broken in the .otf fonts (in that ZIP). Perhaps you should download the ZIP and check those fonts. Maybe the wrong files got in there somehow. I'm so confused. :-)

[rsms]

Ah, I had not removed the (now redundant) "fix display names" post processing script for the OTFs in the makefile. Fixed. Here's complete dump of all name table entries of otf and ttf files: https://gist.github.com/rsms/dfb57385629167b7fe8fbbb6e9cfb65b

Here's a build: Inter-4.0-b7ed03d0e2.zip

Regarding name ID 16 & 17: fontmake ignores these for fonts where they would be the same as ID 1 & 2, regardless if the UFO fontinfo.plist contains openTypeNamePreferredFamilyName and/or openTypeNamePreferredSubfamilyName entries. It most likely means that ID 16 & 17 are not needed in practice when their values would be identical to ID 1 & 2.