Fontlab 7 - Windows reads exported font name differently

Laurensius Adi

I'm making a font named 'LS Ultra Grotesk' using Fontlab 7.

It's a Multiple Masters, with 6 weights. Here's from Font Info > Instances.

I'm exporting the font to Web PS (otf) using these Instances.

If I install these fonts, Windows doesn't recognize them as a family.

Windows wrongly reads the regular weight as family: LS Grotesk with style: Ultra.

What should I do?

John Hudson

Hmm. Based on what you report, I would be worried that Windows might have an algorithm that treats 'Ultra' as a weight style name. That's just the sort of undocumented behaviour software developers love to hard code into font support.

Thomas Phinney

John’s theory seems likely.

As a test, try changing the family name to, say, “LS Ultre Grotesk” and see if that behaves as expected, or exhibits the same unexpected behavior.

Laurensius Adi

Renaming the font makes it behave as expected.

Any suggestions or workaround so I can keep the original name?
Should I try using numbers?

Peter Constable

John Hudson said:

Hmm. Based on what you report, I would be worried that Windows might have an algorithm that treats 'Ultra' as a weight style name. That's just the sort of undocumented behaviour software developers love to hard code into font support.

The name handling algorithm used in DWrite and WPF has actually been documented for a long time.

WPF font selection model - Microsoft (windows.net)

John Hudson

Thanks, Peter. That is a useful document, if alarming at times. Section D. Extract terms for weight on page 8 suggests why Laurensius is running into problems with his family name.

Laurensius Adi

Thanks for the docs.

I just tried naming the fonts using numbers like 45, 55, 75. Windows still read my fonts as LS Grotesk Ultra, and the bold becomes LS Grotesk Ultra Bold.

I guess I should look for another family name?

Thomas Phinney

That sounds like either (or both!):
- a font caching problem
- you have changed some name table entries, but not all the relevant ones

Adam Jagosz

Just because it's documented doesn't mean it's justified. That's the kind of infuriating  behavior developers love implementing because they think they know better.

Tanveer Qureshi

Hi, 
If I am not wrong, you should consider LS Ultra Grotesk into LS Ultra Grotesk Bold.

Thomas Phinney

I think I misread. You were just renaming the styles, but keeping the family name with the "Ultra" in it. Yeah, no surprise that did not help evade the Windows algorithm.

Viktor Nübel

We've just came across a similar issue with the font family name Compact, a font family with 6 styles. (Noticed in Windows 10 and Windows 11, Regular, Bold + Italics will be shown as Sans and SemiBold + SemiBold Italic will be shown as Sans Compact).

Renaming the font family to Compoct would save the problem...

Unfortunately the link name handling document in this thread is broken...

I wonder if this doc is still available (@Peter_Constable ?) or if there are any new discoveries about this issue?

Cesare G.

No problems here.

I downloaded IBM Plex and used ftCLI to change the family name to "LS Grotesk Ultra"  and recalculate the name table.

At first, I thought the problem was due to linked styles (400, 700), so I recalculated the nametable deactivating linked styles.

Here are the nametables of the Regular and Bold styles:



And here's the result: all 12 styles (I left the italics too) are grouped under the same family.


Second attempt: I linked the Regular and Bold styles (400 and 700) and changed the family name to "LU Ultra Grotesk":



Result: also this family is correctly recognised.


Maybe a Fontlab issue? Would be possible to have a dump of the name tables of the fonts?

The edited files are attached

Edit: one last screenshot...

Cesare G.

@Viktor Nübel

Same as above for Compact



Files are attached

Viktor Nübel

Made the same test with IBM Plex Sans renaming it to IBM Plex Sans Compact (in FontLab 7) with the same result: Windows Fonts Folder put the files to IBM Plex Sans familiy. So it seem to be an automatic rule by Windows ... (?)

Cesare G.

Viktor Nübel said:

Made the same test with IBM Plex Sans renaming it to IBM Plex Sans Compact (in FontLab 7) with the same result: Windows Fonts Folder put the files to IBM Plex Sans familiy. So it seem to be an automatic rule by Windows ... (?)

Would you attach the fonts?

Viktor Nübel

Sure

Cesare G.

This is very strange and seems definitely a Windows bug to me.

Anyway, adding nameID 16, even if its string is exactly the same as nameID 1, seems to solve the problem. This just destroyed my certainties.



Find the files attached

Adam Twardoch

I see that in the original font files, the Typographic style name (TSN / NID 16) for all fonts is "LS Ultra Grotesk", and the Styling group name (SGN / NID 1) in two styles (Regular and Bold) is the same as NID 16. 

But after the re-calculation, NID 1 of the Regular and Bold fonts becomes "LS Ultra Grotesk Regular" — and that seemingly fixes the problem? 

It may, but it introduces other problems: apps that use TSN / NID 16 may write it ("LS Ultra Grotesk") into, say, .rtf or .docx, and then another app that only looks as SGN / NID 1 will try to load the font "LS Ultra Grotesk" but it won’t, because there is no single RBIBI group with that name. That’ll lead to problems.

Peter Constable

I downloaded the IBM-Plex-Test.zip file and looked at the name entries --- seemed OK --- and installed all 18 fonts. In both the legacy Fonts control panel and in Settings > Personalization > Fonts, all 18 styles appear under the family name IBM Plex Sans.

Isn't that what you wanted?

Cesare G.

Adam Twardoch said:

I see that in the original font files, the Typographic style name (TSN / NID 16) for all fonts is "LS Ultra Grotesk", and the Styling group name (SGN / NID 1) in two styles (Regular and Bold) is the same as NID 16. 

But after the re-calculation, NID 1 of the Regular and Bold fonts becomes "LS Ultra Grotesk Regular" — and that seemingly fixes the problem? 

It may, but it introduces other problems: apps that use TSN / NID 16 may write it ("LS Ultra Grotesk") into, say, .rtf or .docx, and then another app that only looks as SGN / NID 1 will try to load the font "LS Ultra Grotesk" but it won’t, because there is no single RBIBI group with that name. That’ll lead to problems.

Probably my mistake while using the command line.

Cesare G.

Peter Constable said:

I downloaded the IBM-Plex-Test.zip file and looked at the name entries --- seemed OK --- and installed all 18 fonts. In both the legacy Fonts control panel and in Settings > Personalization > Fonts, all 18 styles appear under the family name IBM Plex Sans.

Isn't that what you wanted?

It doesn’t look correct to me. If nameID 1 is “IBM Plex Sans Compact” and nameID 16 is not present, those 4 styles should be grouped under the “IBM Plex Sans Compact” family. Adding the apparently redundant nameID 16 seems to fix this.

Peter Constable

Cesare G. said:

It doesn’t look correct to me. If nameID 1 is “IBM Plex Sans Compact” and nameID 16 is not present, those 4 styles should be grouped under the “IBM Plex Sans Compact” family. Adding the apparently redundant nameID 16 seems to fix this.

Oh, you're right: I hadn't noticed that.

In the WPF Font Selection Model algorithm, "Compact" is treated as a stretch (width) axis keyword. That's why "Compact" in name ID 1 is being handled the same as if there were a name ID 16 string "IBM Plex Sans" and name ID 17 string that includes "Compact".

That algorithm was devised 20 or so years ago intentionally to deal with cases like that: there were existing fonts with name IDs 1 and 2 but not 16/17 and that accommodated apps that assumed the RIBBI model by putting width terms into the Family (name ID 1) string. To get those existing fonts working in the WSS family model used by CSS2 and WPF, the Family and Subfamily strings (1/2) are reanalyzed to get fonts into WSS family groupings. IIUC, a large collection of existing fonts from major vendors were examined to see what weight or width terms were found in name ID 1 strings.

So, is "Compact" in IBM Plex Sans not intended to indicate a narrower width?

Paul van der Laan

Perhaps it might help if bit 8 of fsSelection in the OS/2 table is set (“font naming follows WWS naming scheme”). The Plex Compact fonts do not have that bit set now.

https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fsselection

Viktor Nübel

Thanks Peter, Adam and Cesare for the insights and tests!

We will now solve the problem by adding a nameID 16 (by hand) which is the same as nameID 1.

Peter Constable said:

So, is "Compact" in IBM Plex Sans not intended to indicate a narrower width?

Yes, "Compact" is the SemiCondensed style of the font family (we just used IBM Plex for testing), but it is intended to be shown as an own family (as InDesign would do it).

(Just found that Adobe describes "Compact" also as a width attribute:
http://wwwimages.adobe.com/content/dam/acom/en/devnet/font/pdfs/5088.FontNames.pdf well described here: https://glyphsapp.com/learn/naming )

Paul van der Laan said:

Perhaps it might help if bit 8 of fsSelection in the OS/2 table is set (“font naming follows WWS naming scheme”). The Plex Compact fonts do not have that bit set now.

https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fsselection

Thanks Paul, good idea, I could test it, but I have no idea how to set fsSelection bit 8 (in OTM) ...

Paul van der Laan

Viktor Nübel said:

Thanks Paul, good idea, I could test it, but I have no idea how to set fsSelection bit 8 (in OTM) ...

Apparently OTM shows these values in hexadecimal. You need to add 0x100 to the values that you see there. So in the example above: 0x0120.

Adam Twardoch

The recommendation not to put NID 16 is it were to be identical with NID 1 was done in early days of OpenType and I think was built into AFDKO. All Adobe fonts were made this way. But I never saw any »hard« arguments for this practice, only that it's to avoid data duplication (which is minimal).

But this thread shows that MS treats fonts with NID 1 only differently than fonts that have identical NID 1 & 16. So we need to reevaluate this recommendation of "optimizing NID 16 away". Thanks for all the info! 

Cesare G.

@Paul van der Laan

Bingo!

I added some lines to ftCLI to set/unset fsSelection bit 8.



Only the four styles changed by Viktor Nübel had that bit cleared (as you can see in the above image, only those files have been modified).

Result: it works as expected.


Files attached

Paul van der Laan

Great to hear that did the trick! I suspect that WPF skips any heuristics on the font naming if the OS/2 fsSelection WWS bit is set.

I know IBM Plex has these bits set by default because I’ve mastered them myself.

Viktor Nübel

Thanks Cesare, you were faster than me :-)

Viktor Nübel

Paul van der Laan said:

I know IBM Plex has these bits set by default because I’ve mastered them myself.

Always great to learn from the best! :-:smile:

Adam, is set/unset fsSelection bit 8 something for the Fontlab wishlist (Other Values) ?