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

This is outrageous. 

They issued an update, but it did even worse, because additionally to the spacing issues, which are not resolved, it's now impossible to view and print out some documents with tables, because some text in the cells is not visible for merged cells (if two cells in two neighbour rows were merged).

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!!

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.

Dieter's post prompted me to open my problem document with Word 2016 MSO (16.0.8431.2046) 32-bit. This document does not use the "Use printer metrics" compatibility option fix recommended by Suzanne Barnhill, so I would expect it to behave properly after updating the various field codes if a fix had been implemented.

Unfortunately, the problems are still evident — and in fact, the document seems more unstable than it was in February when I first encountered the problem.

1. Word's status bar shows that it is 323 pages and 56 sections — no wait, now 49 sections... and now 54 sections... Huh?
2. The document uses 11pt Adobe Garamond Pro, with most body copy line spacing set to single.
3. The index starts on page 313 of 323 (and section 53) is page number 299 (14 pages of front matter are not numbered or use Roman numerals). yet the table of contents variously reports page 362, 364 and eventually 344 after choosing to update the page numbers only.
4. Numbers in the index are way off: one showing as being found on page 358 has its associated XE field code on page 293. After pressing F9 to update the index, it now reports that the entry is on page 361.

Just to be sure, I opened the same document that had been fixed using Suzanne Barnhill's workaround:

1. Word's status bar reports 396 pages in 56 sections, with the final page numbered as 382 (which matches the final PDF print).
2. Although the body copy still uses 11pt Adobe Garamond Pro with line spacing set to single, the printed & PDF results are now an accurate reflection of the expected more open spacing of the font compared to the supposedly-WYSIWYG on-screen view of the problem document (see screen shot below).
3. The ToC consistently reports that the Index begins on page 369 after updating the page numbers.
4. Numbers in the index are correct, and stay correct after successive updates. The entry cited above correctly shows that its associated XE field code is located on page 362.

Here's a composite screen shot comparing the same paragraph from the documents without and then with the "Use printer metrics" fix. It shows that the screen view of the fixed version matches the resulting PDF precisely. The PDF from the unfixed document uses the same line breaks, but clearly shows the very different line spacing.

While my document is probably larger and more complex document than what a typical Word user might create, it is typical of many I have done without any such problems over the years. Moreover, it uses features and capabilities — and the "Pro" type fonts — that many corporate Word users would use routinely.

I can appreciate that the bug may be esoteric, and complicated to fix, but it seems to me that Microsoft needs to assign a much higher priority to coming up with a proper resolution to the problem.

Our marketing department got severely effected by this problem. They use ArnoPro, MinionPro, and Helvetica, etc. When they Pdf, leader dots disappear, text gets pushed down and spacing is off. 

I had to waste their time and mine downgrading to 2013 and now they dont even offer the 2013 download in Office 365! Its discontinued!

Two years and nothing fixed, they are not taking it seriously and I hope there is some legal recourse!