When I use garamond bold italic in Word 2013, it appears as a san serif.

[cassandrab42602363]

It prints and pdfs fine, it is just how it appears in Word. I have tried uninstalling and reinstalling. My IT person thinks that it is a problem with the way Word and Adobe interact. I rely on this font as it is a company branding issue. I cannot format in Word because the font doesn't appear correctly. I have tried deleting the pfm and pfb fonts from the computer. I have tried reinstalling all fonts manually as well as deleting repetitive font names manually. Nothing seems to work. See below for an example. I can't imagine why this font would appear in Adobe programs just fine, but only seems to have an issue in Word 2013. This is the third machine I have had this problem with. I am at my wits end. I am not sure how to fix this problem. Any suggestions?

[Dov Isaacs · Accepted solution]

Adobe has never offered a font or font family with the simple name “Garamond.” Adobe has offered Adobe Garamond (Type 1 and subsequently OpenType CFF formats) and Garamond Premier Pro (OpenType CFF format) families, both Adobe designs, as well as ITC Garamond, Garamond 3, and Stempel Garamond licensed from other foundries.

My initial assumption was that the “Garamond” that you are most likely using is the Garamond family installed by Microsoft Office, licensed by Microsoft from Monotype. Ironically, this font family only has regular, italic, and bold faces. There is no bold italic face with that particular Garamond family. And apparently, for some reason, your Windows configuration refuses to “synthesize” a bold italic faux style for Garamond by obliquing Garamond Bold. (I am successful in doing this on my systems - I don't know why it doesn't work on yours).

However, you mention uninstalling and reinstalling .pfb and .pfm files. That would be indicative of a Type 1 version of a Garamond font family. What I did find what that the old Type 1 ITC Garamond fonts licensed by Adobe indeed had a Windows application menu name of Garamond. That may be what you have been using.

If that's the case, the cause of the problem is unfortunately very simple. Microsoft no long supports any Type 1 fonts (i.e., the fonts with .pfb and .pfm files) for Microsoft Office under Windows starting with Office 2013, although the Type 1 font names may appear on the font lists. What is probably happening is that Word is using the Monotype TrueType version of the regular, italic, and bold faces of Garamond but then has no direct substitute for the Type 1 bold italic face of Garamond, thus using Arial Bold Italic. That is consistent with the sample you display. (The Garamond in your sample does ​not ​look like ITC Garamond!)

Since Adobe applications continue to fully support the old Type 1 fonts (although we no longer sell licenses for them), you don't see this problem in any Adobe application.

For better or worse, there is nothing Adobe can do to assist you with this since the problem is neither caused by any Adobe software nor can it be fixed by anything from Adobe. And Microsoft has no intention of supporting Type 1 fonts going into the future. They do support TrueType, OpenType TrueType, and OpenType CFF (Type 1 outlines) fonts now!

What are your alternatives? You could license TrueType, OpenType, or OpenType CFF versions of some version of Garamond from Adobe or some other vendor after carefully matching what you currently have in terms of style with Garamond fonts available. (Note that there are dramatic differences between the available Garamond typeface families even though they all have “Garamond” in their names!) You will probably need to modify your branding documents and document libraries to reflect the new font name(s).

Yes, this is a royal pain in the tuchas, but it was Microsoft's choice to stop supporting Type 1 fonts. 

Let us know if there is anything we can further assist with in terms of this issue.

          - Dov

[cassandrab42602363]

Thank you so much. I do have Adobe Garamond and ITC Garamond on my computer. I will talk to our corporate office about utilizing one of those fonts instead. What a pain. I appreciate you taking the time to respond even though this isn't technically an Adobe issue.

[WQEric]

I found your useful reply while researching a similar problem I have encountered with using Word 2016 and the Adobe Garamond Pro font family (i.e. not the built-in Garamond face per the OP).

A document created with Word 2010 using the Adobe Garamond Pro font family worked as expected with correct pagination and, more specifically, correct page numbers in the generated index. When I open the document with Word 2016, it appears to be okay, and I attributed the slight differences in pagination to different layout settings. However, the index reports page numbers that are consistently ~25% off. For example, a term marked on page 342 is shown in the index as being on page 430 — despite the fact that the document has only 410 pages in total!

I confirmed that this is related to the font by changing to different faces (Times New Roman and Segoe UI). In both cases, after repaginating and rebuilding the index, the page numbers are correct. Returning to the Adobe Garamond Pro font causes the incorrect page number reporting again.

Your reply is the first I've found that may explain the problem. However, I am unsure how to tell if the font face I purchased from Adobe in September 2011 is a Type 1 font. When I open it in the Windows 10 Fonts folder and preview a face, it displays the following:

     Font name: Adobe Garamond Pro

     Version: Version 2.115; PS 2.000;hotconv 1.0.70;makeotflib2.5.5900

     OpenType Layout, Digitally Signed, Postscript Outlines

Per your response above, the "OpenType" in the above would lead me to think that this font should be compatible with versions of Word after 2010, but is there any way to know for sure?

And if my versions of this font family are no longer compatible, does Adobe have a newer version of the Garamond family that will work correctly with Word 2016?

Thanks!

[Dov Isaacs]

Adobe Garamond Pro is indeed an OpenType CFF font, not a Type 1 font.

In our experience, there is nothing intrinsic about Adobe Garamond Pro that doesn't work correctly with Word 2016. What happens if you rebuild the index after changing the font to Adobe Garamond Pro?

          - Dov

[WQEric]

Thanks for the quick response Dov Isaacs! I have been rebuilding the index after changing the document's font each time — and the only time I get incorrect page numbers is when the document is using the Adobe Garamond Pro family (AGP).

A spot-check of the index shows that the page numbers are reporting ~25-28% over what they should be after changing the document to the AGP family. An index term marked on page 1 shows correctly as being on page 1; but one on page 188 shows as being on page 239 (~27%); one on page 316 as 398 (~26%); and the final XE field on page 356 shows as being on page 445 of the 410-page document (~25% off).

I just tried the procedure again on a different document from Word 2010 days that also used the AGP font family. When I opened it, I could see that the index references incorrect page numbers. When I changed that document's font to use the Segoe UI family, the rebuilt index is displaying correct page numbers.

Ditto after changing to the Arial font family and rebuilding the index. Here's a screen shot of my split view in Word 2016 showing the page containing the XE field code marking the index item in the upper pane (page 348 when the Arial font is used), and the index entry in the lower pane correctly referencing that page's number.

The following screen shot shows the same parts of the document after changing the fonts to the AGP family. The upper pane shows the content with the XE entry being on page 280, yet the rebuilt index in the lower pane is incorrectly showing it to be on page 326.

This problem only occurs when the AGP font is used in both of my test documents.

I had hoped that you would confirm that my AGP font was an older version, and that just updating it would solve the problem because the book needs to use the same font as the previous editions. Now I'm really stumped!

I am quite willing to make the document available if someone at Adobe wants to replicate my tests to analyze this behavior.

[Dov Isaacs]

I certainly believe that you are seeing the symptoms that you describe and that there is a problem. However, there is absolutely nothing in a font's definition that could cause something like this by itself. All the font has is outlines of the individual glyphs (i.e., the characters), “hinting” (information on how to render the characters at lower magnifications), and metrics including the width of the character, pair kerning information, font characteristics, etc.

My best guess is that somehow for OpenType CFF fonts, Microsoft may be misinterpreting some of the metrics within the fonts when building the index. But that is somewhat of a WAG.

Three recommendations:

(1)     If you have any other OpenType CFF font families (all the Adobe “Std” and “Pro” fonts are OpenType CFF format), see if using them causes the same symptoms. (My bet is that the symptoms might be occurring with all OpenType CFF format fonts). Let us know!

(2)     Make sure you have all the updates to Word 2016. It seems like I am getting updates / bug fixes to Microsoft Office 2016 almost every week. If there are any available updates, apply them and see if the problem is still occurring.

(3)     Contact Microsoft Technical Support. If they really believe there is a problem with these fonts, they can better instrument what is going on and if they truly believe there is a problem with the Adobe fonts, they can work directly with us. (We do work very closely with Microsoft on type issues and other issues.)

Let us know what transpires.

          - Dov

[WQEric]

I've also been thinking that some part of Word's pagination calculation algorithm is not using the font's metrics properly.

(1) Unfortunately I don't have any other OpenType CFF font families to test if I see the same the behavior. (My document is ~1.9MB. I assume you have access to any number of these fonts, so if you would like to rule that out, I can send you a link to it. Let me know by email.)

(2) I use the subscription version of Word 2016, so it is kept fully up-to-date. I'm currently running v1701 (build 7766.2060).

(3) I am not sure how to contact Microsoft Technical Support, but will certainly make the effort based on what I've learned (see below).

Your reply prompted me to do further testing that seems to confirm that this is a problem with Word, and not the fonts.

I created a 400-page "Lorem ipsum" dummy document with a single Section, and placed a few XE fields within it to see if it would report incorrect page numbers in an index. The result? All page numbers were accurately reported. That was a surprise, but the dummy document was very simple, with just one paragraph style and the default page layout in a single section.

Since my problem documents are considerably more complex, I wondered if the sections might be a factor. The most recent one has 56 sections using a book layout with different first-page and odd- and even-page headers and footers. Accordingly, I used Find & Replace to change all section breaks to manual page breaks to change it to a single section. After I then rebuilt the index, the page numbers were correct!

I believe this confirms your earlier assessment that the fonts are not likely to be the problem — and points to a problem related Word's pagination (or index generating).

To be more certain, I will strip out and then recreate all 56 sections to ensure they are all identical in their dimensions. Most of the headers are linked, and use Styleref field codes to display the current chapter names so this is not a particularly onerous task. If I then find that the index reports correct page numbers, I will assume there was a glitch in one or more of my original sections. If the page numbers are still being reported incorrectly, I will contact Microsoft Technical Support to see if they would be willing to examine the document to see if they can find a cause.

I'll let you know by updating this thread. Thanks for your help @Dov Isaacs!

[Dov Isaacs]

I admire your discipline in testing this out! 

Please let us know the outcome of any interaction with Microsoft on this issue and how it gets resolved.

          - Dov

[WQEric]

Update: Since I did not have any other OpenType CFF fonts, and the Adobe Garamond Pro family I have is from 2011, I started a subscription Adobe Typekit account. This let me update the AGP font family I have been using, and also synch a different font family (Minion).

I repeated my tests as earlier. The document's index shows incorrect page numbers when either the AGP or Minion fonts are being used. When I use Times New Roman or Segoe UI fonts, correct page numbers are shown in the index.

In each case, visibility of all hidden text and non-printing characters was turned off; all field codes were resolved to results; the document was repaginated; and the index was rebuilt. I believe my results indicate that there may be a bug in how Word uses metrics within the OpenType CFF fonts when it builds an index.

Two final font clarification questions for dov before I post this to Microsoft Technical Support:

1. Am I correct in thinking that the Minion Pro and Adobe Garamond Pro are both OpenType CFF fonts?
   
   
2. If both are the same variety of OpenType, how should I communicate the differences between them and the Segoe UI or Times New Roman fonts? (see below)

Unlike the other fonts on my Windows 10 system, Typekit synched fonts do not appear in the system's Fonts folder so I am unable to examine their properties. Like the AGP fonts before I removed them, the Segoe UI and Times New Roman fonts both show as "OpenType Layout" — but their version and outlines information differ. This is what the Segoe fonts show:

And this is what my installed AGP fonts showed before I removed them to allow the synched versions to function:

[Dov Isaacs]

Adobe Garamond Pro and Minion Pro are both OpenType CFF font families. Times New Roman and Segoe are both OpenType TrueType font families.

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.

I am wondering whether Word is doing something that assumes that 2048 value (it shouldn't) for font character widths being based on. It is crazy enough to actually be the issue and about the only thing that I can think of that just might be the root of the problem.

          - Dov

[WQEric]

Thanks dov​. I've posted about this issue on the Microsoft Developer Network Forum [here], so I won't take up more of this thread. It has been very useful, and I thank you for your help. /Eric