macOS doesn't like the “Poster” as a last word in a family name?

Michael Rafailyk

Just ran into this strange behavior on macOS with the Poster word in the font family name suffix like "Fontname Poster". Any other two-words family name works ok but not a Poster as a second word. Looks like the text engine treats this word as a style (but not a family) name?

For clear test I exported the same set of outlines twice under the different family names: "Testm Poster" and "Testm Display". This is how one of the exported fonts looks like:

Family name: Testm Poster

Weight class: Regular 400

Style name: Regular

Full name: Testm Poster Regular

PostScript: TestmPoster-Regular

Style group: Testm Poster

Adobe font menu show me the wrong styles order for Testm Poster family:

And TextEdit doesn't show Regular and Italic at all:

But if I install only pack of four base fonts (RIBBI), than TextEdit show all of them just in a wrong order:

Is this a known feature/bug of the text engine and should I be concerned?

c.g.

Maybe fsSelection bit 8 is not set to 1?

https://typedrawers.com/discussion/comment/55711

Michael Rafailyk

@Cesare G. Thank you for the link.

As I understood, name ID's 16, 20 and 21 and others fields cannot be specified directly in type design applications, and for that I needed some extra tools and perhaps command line. Sounds very complicated at the first glance.

c.g.

I don't think you need nameIDs 20 and 21, unless you want to group the Poster and Display families together (personally, I don't like this). Probably setting OS/2.fsSelection bit 8 will solve the problem.

Did you check that each weight has a unique usWeightClass value (e.g.: Light: 300, Regular: 400, Medium: 500 etc.)?

Michael Rafailyk

Cesare G. said:

Did you check that each weight has a unique usWeightClass value (e.g.: Light: 300, Regular: 400, Medium: 500 etc.)?

Sure, I have checked every possible value on instances and on exported files, everything looks correct.

Probably setting OS/2.fsSelection bit 8 will solve the problem.

Thank you, I will try it.

Thomas Phinney

Michael Rafailyk said:

As I understood, name ID's 16, 20 and 21 and others fields cannot be specified directly in type design applications

I don’t think this is entirely true. Most type design apps expose nameID 16, last I know of. We used to call this the “preferred” family name.

NameID 20 (CID findfont name) is certainly obscure. NameIDs 21 & 22 are weight-width-slope compatible family and subfamily, respectively. In many cases they will correspond to 16 and 17, unless the family has styles that differ on variables other than wt-wd-sl.

Thomas Phinney

Oops, I forgot to say! “Poster” has historically been used as a style name (e.g. “Bodoni Poster”). I think it is fairly likely that macOS has some interestingly “helpful” heuristics that override the actual data in your font, which are responding to this particular name. This has certainly been seen in other, similar cases.

Michael Rafailyk

Thanx @Thomas Phinney. So here the reason, I knew that!

However I am at the fork now:

• Don't use such a words and just find an equivalent.
• Correct some name ID fields by hand (is it the right way?).
• Just let it go per se

Thomas Phinney

Yes, those are the alternatives, I think.

With the second option, do you mean figuring out which fields are triggering macOS, and changing just those? Yes, that might work technically, but creating inconsistencies… feels wrong to me, at least.

I think #1 is the option I would pick, but… arguably all these options suck, right?

Michael Rafailyk

Exactly Thomas, we don't live in a perfect world.
By name ID fields – I mean to change all that needed to correctly display fonts on both macOS and Windows. But agree, I don't think I will go this way, even if it work.

At the moment I think about the first option and the question is how to name it. The problem is that when we add a new name, the users lose the clarity of the classification.

There are one more option, even more terrible:

• Reduce the count of subfamilies and made Display somewhere in between Display and Poster.

c.g.

@Michael Rafailyk

Would you test these two families (IBM Plex Sans with different names)?

https://workupload.com/file/KvVErVyUGwV

I named them Testm WWS0 Poster and Testm WWS1 Poster.

I'm not a Mac user, so I can't test myself. But you can see the difference in Windows.

If the fsSelection bit 8 is cleared (WWS0), Text styles are not listed in their place between Regular and Medium. With WWS bit set to 1, they are correctly listed. Maybe that bit has some effect on macOS too.

Michael Rafailyk

@Cesare G., thank you for the test on Windows.
Here the results from macOS 10.13.6

Adobe.
Both family's styles are in the right order, and it's better than my own previous test. I compared your and my own files but can't see any difference on a base name ID fields. Interesting.. 


TextEdit.
Regular and Italic didn't appear at all, like in my own previous test.


It is worth mentioning that TextEdit always displays non-RIBBI families in the wrong order (I checked it on system font families like New York and San Francisco), perhaps this is some kind of feature of it. But I expect at least to display all the family styles, even in a wrong order.

c.g.

Michael Rafailyk said:

@Cesare G., thank you for the test on Windows.

TextEdit.
Regular and Italic didn't appear at all, like in my own previous test.


It is worth mentioning that TextEdit always displays non-RIBBI families in the wrong order (I checked it on system font families like New York and San Francisco), perhaps this is some kind of feature of it. But I expect at least to display all the family styles, even in a wrong order.

Wow! Not even in alphabetical order. The Windows counterpart, notepad.exe, handles it perfectly:



Another try: I unlinked the Regular and Bold styles, adding nameIDs 16 and 17 also where apparently not needed. See attached file.

Michael Rafailyk

@Cesare G.
Just checked, looks like unlinking didn't help.
TestX Poster showed the same result as Testm WWS1 Poster, in all applications.

c.g.

Ok. Seems a Textedit/macOS bug to me (someone would call it a “feature”). I’d like to see what happens with Next Book/Poster by Optimo.

https://optimo.ch/typefaces/next

c.g.

I managed to test the fonts on the MBA of a friend.

The last files work for me (TestX Poster).

Both in Fontbook and Textedit "Regular" and "Italic" are listed on top, the others are sorted by weight.

Michael Rafailyk

@Cesare G. thank you for this additional test.
Yes, Font Book on my Mac is also works well with the Poster subfamily.

Looks like your friend has a newer version of macOS than mine. I'm glad that the new version of TextEdit shows all font family styles, that's really good news!