BUG!! Word 2016 fails to print margins correctly / messes up layout (Possible OpenType .otf Font bug)

If you read any book about typography line spacing is defined as the sum of a font size and leading (see Wikipedia https://en.wikipedia.org/wiki/Leading) both are values in the unit points defined as 1/72 inch due to typographic history and completely independent for a certain font design. The result always is an exact decimal value. A kind of "Arial line spacing" or "Minion line spacing" doesn't exist. The leading is not part of the font design. The only indirect line spacing feature as part of a font design is, that a 10pt Arial compared to 10pt Times New Roman need not to give the identical size impression (the visual glyph sizes need no to be identical). But the line spacing defined as font size  + leading i.e. 10 +2 = 12 must be the exact value independent from the chosen font, otherwise a typographic designer wouldn't be able to design so called line grids (http://thinkingwithtype.com/grid/)  for books using different fonts.

But the best esthetic line spacing is dependent from the chosen font and the used fon sizes, yes that's true. But a line spacing value of 1, 1.22 etc. is an exact decimal number. To combine this exact number with obscure dynamic factors derived from a certain font (which factors?) contradicts to an intuitive usability concept: So at least this line spacing should be called "Microsoft automatic" then I immediately know this is a kind of an implemented bug, like all other features in Word named with "auto..."

I must say this because all automatic Word features result in bugs because Microsoft never implement functions based on use cases but on statistical behaviors of customers (Example: if a customer uses a number at the beginning of a sentence this is because he wants to introduce a list, so let's automatically adjust a list style and a list format to this sentence). And Microsoft never tests implemented features against typical (very different) use cases. Otherwise they would have realized the side effects that all automatic features imply, at least if you want to use Word for longer documents. So this is the same with the obscure Open Type line spacing feature. The incorrect page numbers in TOC and index I think are also due to the strange line spacing calculation.

My organization uses Minion as our standard font, so it really is a BIG deal.

I think what's most interesting about the problem, is that in researching Minion and OTF fonts, the OTF font was developed JOINTLY by Microsoft and Adobe to ensure cross-compatibility. #FAIL

The issue is with any fonts that originated as type 1 PostScript fonts — which includes most of Adobe's "Pro" fonts (like Minion, Garamond, etc.). In a thread about this topic on an Adobe site where I started to try to resolve this issue, an Adobe font specialist said:

“The primary difference between the OpenType CFF and OpenType TrueType fonts is the outlines and hinting technology used by the font. OpenType CFF uses the same Bezier curve and hinting mechanism used by the original Type 1 fonts used in the original PostScript printers and use a coordinate system based on 1000. OpenType TrueType uses the quadratic curves and programmatic hinting mechanism used by TrueType fonts, using a coordinate system based on 2048.”

That certainly held true for my testing*.* I even joined the Adobe TypeKit program to have access to their excellent fonts, but cancelled the subscription when I learned that Word was unable to cope with them*.*I too find it surprising that this would still be unresolved, since Microsoft's corporate clients are quite likely to use such fonts as their standard for documents.

Hey all

I'm surprised/not surprised that Microsoft has not replied to this post but let me fill you in. 

As an Enterprise customer with 8500+ affected machines, I did open and escalate this issue with Microsoft a number of months ago. They have acknowledged the problem and are currently working on a HotFix - involving both the OS and Office engineering teams. The last update I received about 10 days ago was that I should have a patch to test in November/December, with a worldwide release in December/January (assuming all goes well). 

The only workaround that was feasible for us was to install Word 2013 in parallel to Office 2016 for my users that had critical need. Everyone else is either avoiding OTF fonts where they can, or delaying their projects until a permanent fix is deployed. 

My organization uses Minion as our standard font, so it really is a BIG deal.

I think what's most interesting about the problem, is that in researching Minion and OTF fonts, the OTF font was developed JOINTLY by Microsoft and Adobe to ensure cross-compatibility. #FAIL

The problem is more than just with the line spacing.  I first encountered the problem in a large (200+page) book when I noticed that the page numbers in the index were incorrect. I could see that the line spacing was different, so adjusted it to fit what Word appeared to be using. This helped, but the page numbers were still off. The different metrics being used by the two types of OpenType fonts cause very small changes in how the letters fit as well.

I doubt if typographers would want Word to use a line spacing value (“leading”) based only on the point size. The leading value is part of the font’s design—although you can override it by specifying an exact line spacing in the Format Paragraph dialog. The “single” spacing option will use whatever was designed for the font, and other variants like the new default of 1.15 lines will use 115% of the built-in leading designed for the font face.

However, if he is part of the Office Insider program, he will have a newer (and potentially less stable) version.

Yes I think I am included as part of Office Insider. Obviously our IT department could include this solution for me as an option of the Office Update feature. By the way I use the 32 Bit version.

And yes I think Microsoft has completely underestimated the problem. It may be that the current line spacing algorithm includes a faulty calculation method:  This calculation should be independant from any font but only defined by a multiple of the font size.