This is a(nother) weird one but this will make it work: Go to Font, Advancend and then choose “Use contextual alternates”. (Kerning for font XX Points and above has to be ticked as well.)
Thanks! Yes that works! Crazy. So I need to prepare a special instruction sheet for the client, great!
I just realised that, somehow my .otf had no "kern" table. (only a GPOS) After adding/copying the kern table (e.g. from another .otf generated with another font editor) it worked as well (without the "Use contextual alternates") But I am not sure if this can cause problems.
It might be related to issue #6 from our OpenType Layout Feature Support Differences:
If a font only contains a DFLT script, then both Windows 10 and Word
(version 1701) won't use the kern feature. However Word will use it if
you also enable another OpenType feature (e.g. Ligatures or Stylistic
Sets)!
I've seen this problem with fonts that also explicitly declare 'latn' script support. Still need to enable something else to get kerning to work, on latest Word for Mac. Microsoft is aware of the issue—I reported it again in January.
@Ben Kiel & @Thomas Phinney, thanks again! It seems that MS Word activates kerning of .ttf files (with a kern table) without the additional check of the "Use contextual alternates" checkbox.
Anyone has experience with things like exchanging documents, which uses either .ttf or .otf.
I mean if one creates a .docx that contains font.otf and tries to open it on a cpu that has only font.ttf installed? (and vice versa)
Will MS Word (Office or other apps) complain, that font.otf or font.ttf is not installed? (although I already assume that it will complain)
Word and other MS Office apps do not complain proactively about missing fonts. I do wish they would. Especially PowerPoint! It is possible to check, but not obvious.
Last time I looked into it, Microsoft Office apps only reference fonts by name. They do not care about format differences, so opening a doc while having the same-named font in a different format still displays the document in that font, without any error or warning.
(Personally, I think this is an entirely reasonable behavior for an office-class app. I also think Adobe’s not automatically using the other-tech font, for CC apps, is reasonable. Different target audiences with different needs.)
If the font is not there at all, all the Microsoft Office apps will silently substitute another font for it. The document opens fine, without warnings. Putting your cursor in the text displays the name of the intended font in the Font drop-down menu, while silently substituting something else.
This has always disturbed me. It feels like the app is lying to me. I have seen it lead to confusion with users who will swear that they know what font X looks like, and they are wrong... because Office just (in effect) lied to them.
Thomas Phinney said: If the font is not there at all, all the Microsoft Office apps will silently substitute another font for it. The document opens fine, without warnings. Putting your cursor in the text displays the name of the intended font in the Font drop-down menu, while silently substituting something else.
This has always disturbed me. It feels like the app is lying to me.
LibreOffice handles this situation better: the missing font's name is displayed in italics.
In W/X/P there is a distinction between "simple" and "complex" text runs: in a simple run W/X/P will not run full shaping process, while in complex mode it will. Enabling Contextual Substitution will force Word to run text in complex mode so the features will be enabled.
So why simple text mode exists? For performance, of course (yes shaping is a very slow process).
Firefox and Chrome used to have this simple text/complex text distinction, but eventually both killed it for good. Performance for so called complex text benefited from the optimization that resulted from forcing everyone to use the (what used to be) slow path and so called simple text benefited from having good typography enabled by default.
Comments
So I need to prepare a special instruction sheet for the client, great!
I just realised that, somehow my .otf had no "kern" table. (only a GPOS)
After adding/copying the kern table (e.g. from another .otf generated with another font editor) it worked as well (without the "Use contextual alternates")
But I am not sure if this can cause problems.
It seems that MS Word activates kerning of .ttf files (with a kern table) without the additional check of the "Use contextual alternates" checkbox.
Last time I looked into it, Microsoft Office apps only reference fonts by name. They do not care about format differences, so opening a doc while having the same-named font in a different format still displays the document in that font, without any error or warning.
(Personally, I think this is an entirely reasonable behavior for an office-class app. I also think Adobe’s not automatically using the other-tech font, for CC apps, is reasonable. Different target audiences with different needs.)
If the font is not there at all, all the Microsoft Office apps will silently substitute another font for it. The document opens fine, without warnings. Putting your cursor in the text displays the name of the intended font in the Font drop-down menu, while silently substituting something else.
This has always disturbed me. It feels like the app is lying to me. I have seen it lead to confusion with users who will swear that they know what font X looks like, and they are wrong... because Office just (in effect) lied to them.
So why simple text mode exists? For performance, of course (yes shaping is a very slow process).