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

My ongoing tests show, that  my current Word version 16.0.8.528.2084 32-Bit does not fix the OpenType line spacing calculation bug of Word:

The number of pages calculation is like this:

1. While using fixed line spacing based on pt values (i.e. line spacing is 13 pt or at least 13 pt). I get the identical number of pages in Word and in the converted PDF file, even If I update fields like TOC
2. If I use line spacing values like 1 or 1,1 etc. I get different number of pages in Word on-screen and in the converted PDF.

The situation is full of "Microsoft secrets": If I update my TOC field Word shows for a short time I get the the same number of pages like in the converted PDF. My sample document has 37 pages on-screen in Word and in the converted PDF file. But after some seconds the Word document has 39 pages and the TOC shows of course wrong page numbers. If I update the TOC again, the Word document shows again for a short time 37 pages but changes the number of pages dynamically to 39. Converting to PDF always results in 37 pages.

So Microsoft has not fixed this severe bug yet.

Hi!  I was wondering if you could provide an update on that hotfix?  I've just learned within the last week or so that my entire company is also afflicted by this problem.  We just upgraded to Office 2016 and also use Minion Pro as part of our brand.  No workaround is a satisfactory long-term solution, so I'm wondering if there's any information about when this will be permanently fixed?

thanks!!

Thank you EricQc's for the update. You are the only one that actually is making sense. 

We published our first book (600 page statistic book) using Word 2007 with no problem. I am close to finalizing our second 600 page statistical book only to find I can't convert it to a PDF or even print it properly though it looks great on the screen.

Ironic that I was planning to publish in January. I can't believe that there isn't an uprising and lawsuits.

Outraged.

You are absolutely correct about leading Dieter. I was thinking about the font's "x" height when I wrote that. A single-spaced 12pt face with a large "x" height like Cambria should end up with exactly the same number of lines on a given page as a single-spaced 12pt face like Book Antiqua with a small "x" height.

However, for my project with the incorrect index page numbers, when I did set the line-spacing to an exact value (rather than single spacing), the numbers were still off. This would seem to indicate that the index was using page numbers that had been calculated from the index marker's location rather than the actual page where they existed when the printer driver had done its layout.

My "fix" was to use an inferior alternative to the Adobe Garamond Pro font face that did not use the CFF version of OpenType. I have subsequently redone the book with the Adobe font using the fix suggested from these forums, and the problem was eliminated.

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.