Fontlab 7 - Windows reads exported font name differently
Laurensius Adi
Posts: 45
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?
What should I do?
0
Comments
-
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.
4 -
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.2 -
Renaming the font makes it behave as expected.Any suggestions or workaround so I can keep the original name?
Should I try using numbers?
0 -
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.
WPF font selection model - Microsoft (windows.net)
3 -
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.0
-
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?
0 -
That sounds like either (or both!):
- a font caching problem
- you have changed some name table entries, but not all the relevant ones0 -
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.
1 -
Hi,
If I am not wrong, you should consider LS Ultra Grotesk into LS Ultra Grotesk Bold.0 -
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.0
-
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?
0 -
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...
0 -
-
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 ... (?)
0 -
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 ... (?)0
-
-
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 attached0 -
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.0 -
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?0 -
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.0 -
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?1 -
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.
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?2 -
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.
1 -
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.
Thanks Paul, good idea, I could test it, but I have no idea how to set fsSelection bit 8 (in OTM) ...
0 -
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) ...
0 -
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!1 -
@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 attached0 -
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.1
-
Thanks Cesare, you were faster than me :-)
0 -
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) ?
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports