Word for Mac style linking behaviour

Artur Schmal

I've been at war again with Word for Mac for a while now. I don't remember coming across this particular issue before.
The issue seems to occur with weights above weightclass 400.

Here's the issue:

1. I'm selecting the Black weight from the font menu. That goes well, but I notice it activates the Bold button, even though this weight is not style linked as Bold of another weight. It is only style linked with Black Italic.
   
   
2. Then I'm enabling the Italic button, but this gives not the desired result. It shows a fallback font.
   
   
3. If I disable the Bold button after that it shows the correct Black Italic style

I've seen this happening also in several other font families from other foundries. For instance to the UltraBlack weight of Adobe's Acumin Pro SemiCondensed family, but strangely enough not to the same weight in the Acumin Pro normal width family.

I've been editing the nametables in various ways to see if there's anything there that could solve it, also the fsSelection settings, but to no luck.

Does anyone have experience with this issue?

Dave Crossland

Did you check the Panose values?

Thomas Phinney

I have not seen this happen unless the font was linked as the "bold" of another style, or the weightclass was below 250.

LeMo aka PatternMan aka Frank E Blokland

Artur allowed me to have a look at the font data in question and the unexpected behavior was caused by a naming issue. Also the fsSelection settings left some room for improvement. So, the problem has been solved. However, I had a look at the specs again and noticed some differences between the latest and older versions. For example, the construction of the Full font name was quite strictly defined in 2008 and allowes more freedom today:

OpenType specification version 1.5 (2008):
‘Full font name; this should be a combination of strings 1 and 2. Exception: if the font is “Regular” as indicated in string 2, then use only the family name contained in string 1.’

OpenType specification version 1.8.3 (2018):
‘Full font name that reflects all family and relevant subfamily descriptors. The full font name is generally a combination of name IDs 1 and 2, or of name IDs 16 and 17, or a similar human-readable variant.’

The original exception for the Full font name for Microsoft platform strings for CFF OpenType fonts has been removed. I recall that there were some discussions about the necessity of this rule here on TD. However, I wonder why specs are changed if things work: after all, aren’t specs not meant to secure proper and consistent handling of the matter on both the short as the long term? There was no real necessity to change the Full font name definition, except perhaps for some cosmetic reasons in case of the Windows-CFF entry, I reckon.

Artur Schmal

LeMo aka PatternMan aka Frank E Blokland said:

Artur allowed me to have a look at the font data in question and the unexpected behavior was caused by a naming issue. Also the fsSelection settings left some room for improvement. So, the problem has been solved. 

Thanks again for looking into that Frank. To elaborate a bit on the naming issue: the "RIBBI" scheme that Glyphs auto-calculated was not picked up by Word on Mac very well. Frank did some tweaking on that and that solved the issue.

Ben Kiel

Worth noting for the Google machine if someone comes across this problem: the more recent versions of Word get really screwy with style linking (more so than older versions) if the Postscript name is over 31 characters (nameid 6). I know @Mark Simonson has found that 30 or less is better at times also.

Ramiro Espinoza

More and more reasons for making linking families only when clients ask for them.

Thomas Phinney

Eh. Link all your italics (or obliques). In most cases, link the regular to the bold as well. But definitely don’t do more than that.

The old Adobe habits of making the Semibold the "bold" style of the Light, and that sort of thing... I definitely would NOT do today.

Ramiro Espinoza

>>Eh. Link all your italics

Why?

Craig Eliason

Doesn't linking establish the relationships between fonts that allow the [I] button or Cmd-Shift-I etc. to work?

Thomas Phinney

Exactly, Craig. At least, for normal apps that use system calls for font handling.
(Adobe, as oftentimes, may be an exception here.)

And if your fonts might be used by non-designers, outside Adobe apps, or in older Windows apps, it is especially important.

Artur Schmal

Ramiro Espinoza said:

>>Eh. Link all your italics

Why?

It's convenient for users to have acces to the italic through a short cut. I use the cmd-shift-i a lot in InDesign for setting italics.

RaseOne

Nearly all of my own fonts are useless as body text so I'm bias but I don't bother with this at all. The behavior is too inconsistent across apps & platforms. It has its place but seems problematic even in that place. Bold & Italic seem to be the only cases in which it makes any sense. Please point out if I'm horribly wrong.

Thomas Phinney

> Nearly all of my own fonts are useless as body text so I'm bias but I don't bother with this at all.

Dealing with this as a product manager, across entire libraries of thousands of fonts, I came to different conclusions. Style linking is moderately important for display fonts, and very important for body text fonts.

Or to put it another way: people expect it to work even on display fonts, if those fonts have the relevant family members that would make it possible. So if you have an upright and an italic, style linking will be expected.

The styling metadata is extra work, but compared to the work involved in designing the fonts in the first place, it’s hardly anything.


> The behavior is too inconsistent across apps & platforms.

That has not been my experience at all. Virtually all major platforms and major apps support bold and italic style linking.


> Bold & Italic seem to be the only cases in which it makes any sense.

That part we agree on.

André G. Isaak

Thomas Phinney said:

The old Adobe habits of making the Semibold the "bold" style of the Light, and that sort of thing... I definitely would NOT do today.

Are you saying this simply because you don't view it as necessary, or can this create actual problems for some applications?

Thomas Phinney

I view it as unnecessary, and potentially confusing. I don’t think there is a general user expectation that selecting a weight other than regular, and then hitting the bold button, will do something specific/useful.

And even if the existence of additional style links were not a surprise, I don’t think there are common/standard expectations as to which weights will link to which other weights, outside of the “Regular > Bold” link. Medium to Extrabold? Semibold to Black? And if you link Light to Semibold, you can’t then link the Semibold to something else. So I don’t even know what the “right” choices would be in some of these cases.

No actual problems as far as I know. EXCEPT (edit) for the “vanishing style-linked fonts on Windows), as Mark S points out below, which is definitely a potential point of confusion. I remember hearing the support issues back in the day. Sigh. 

(Note: In old Mac resource-fork based fonts, you could actually link Light to Semibold and also Semibold to Black. But not with current formats.)

Mark Simonson

I think the biggest problem with linking weights other than regular and bold is that on Windows the "bold" style is hidden from the font menu. So if a family has six weights, all paired as "regular/bold", only the "regular" half of the pair will appear in the font menu. Back when I used to do this, I would periodically hear from Windows users who couldn't figure out what happened to Extrabold or Black, thinking there was something wrong with the font.