I have run into a problem whereby Scrivener seems to deliver out the wrong font name on compile resulting in the font setting not being recognized further down the road (InDesign).
I have a compile layout aimed at producing docx files set in
Adobe Garamond Pro.
But when the result is opened in Word, Words toolbar widget shows the font name as:
Now, when I place this docx file into my InDesign project, InDesign says it can’t find that font and substitutes the default font (and, by the by, crushes all my italics along the way).
If in the compiled word doc I Select All in Word and pick ‘Adobe Garamond Pro’ in the Word font menu, then Word correctly reports the font as ‘Adobe Garamond Pro’ in its toolbar widget and the resulting docx also imports into InDesign correctly. (In fact, Word seems to understand that the above named font is connected to Adobe Garamond Pro, b/c is displays the correct font and shows a checkbox by that font in its Font menu.)
I gather that ‘AGaramondPro-Regular’ is something like the postscript name of the font and Scrivener is using the Postscript name of the font at a certain point when Compiling instead of the family name of the font, and this is the source of the confusion.
In it’s own font pop-ups, Scrivener duly shows the font to be named ‘Adobe Garamond Pro’.
Compiling to RTF instead of DOCX avoids the problem. The resulting rtf file correctly reports the font as Adobe Garamond Pro. But doing this loses other crucial features for this workflow (stlye specifications are not preserved into the rtf).
Opening the docx, selecting all, and reasserting the font choice of Adobe Garamond Pro from the Word menu fixes the problem.
So, this may be a bug. Scrivener (or the docx java converter) is at some point grabbing the wrong name for the font and using it. Unless of course something is just punky over at my end.