I’m currently trying to wrap my head around a bug in the design software Inkscape. There are some fonts within certain families that do not show up in Inkscape, despite showing up just fine in Adobe Illustrator, Microsoft Word, etc. My current working theory is that the fonts that cause issues happen to have the same weight and width. So for instance: when two fonts within one family only differ by their optical size, or when one font is the outline version of the other. It doesn’t seem to matter to Inkscape that the fonts in question have different style names; it just shows one or the other (not both). It reminds me of a concept from video game graphics called z-fighting.
Out of curiosity, I come here to ask you knowledgable people: how do the other programs do what Inkscape can’t? How do they distinguish between fonts that have identical weight and width? Is it simply the different style names? Any help is greatly appreciated!
I’m not a developer, btw. Only a long-time user of Inkscape who’s helping the Inkscape team by finding issues with the UX in the program.
Usually that is done by looking at the FullName or FontName. And even the family name + style name should be enough. The bug is to look at the weight and width.
Not sure if that’s a bug … I think it has to do with weight/width/slope compatibility.
Some apps/systems require that all styles of a font family differ in the combination of weight class, width class, and italicness (is that a word?). If a family is built this way can be signaled by setting bit 8 (WWS) in the fsSelection field of the OS/2 table.
If there is a style that does not fit into the scheme, the bit should not be set in that font, and name IDs 21 and 22 should be provided to map to a different family name.
In Glyphs, you control the WWS bit with the Custom Parameter “Has WWS Names”, and you set the extra names for each export under General – WWS Family Name and WWS Style Name.
For example, a font with optical sizes should put the optical size name into a separate WWS family:
Family Name: MyFont
Style Name: Text Regular
WWS Family Name: MyFont Text
WWS Family Name: Regular
Family Name: MyFont
Style Name: Display Regular
WWS Family Name: MyFont Display
WWS Family Name: Regular
etc.
So one should probably look at the affected fonts and find out if they employ the WWS logic correctly.
Yes, some apps seem to require this. But the should not look at the width/weight class. Is that what the WWS style names are for? Or do they really fall back to width/weight class if those are not there?
The WPF font selection is based on numerical constants for weight, width, and slope, which are matched to the usWeightClass, usWidthClass and fsSelection italic flag in the OS/2 table.
When the fonts are evaluated, Windows tries to analyze the style names to deduce a standardized weight, width, italic style name and their standardized weight class, width class, and italic numerical values.
So basically the weight and width class settings in your font are ignored. If you don’t want this, set the WWS flag, and the values from the font will be used.
I know for sure that MS Office for Mac works according to this model (we produced a family with separate small caps styles, and had to set the WWS names as I described so that the fonts could be used reliably in Word for Mac).