Font Naming Misfire in Compiled Output

[gr]

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).

DETAILS:

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:

AGaramondPro-Regular

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).

MORE HINTS:

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.

All Best,
Greg

[gr]

@gr

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).

Problem is unresolved, but here is a small correction to my post: the above line should be amended to just read “Compiling to RTF instead of DOCX avoids the problem. The resulting rtf file correctly reports the font as Adobe Garamond Pro.”

[xiamenese]

I was going to post that in my experience, compiling to RTF does preserve all style information. Mind you, I use NWP rather than Word, and Scrivener and NWP go together like strawberries and cream (except I don’t like cream so I personally prefer strawberries and gewürtztraminer! ). I do occasionally check the RTF in Word and I’ve never had a problem with it, other than really disliking Word.

Mark

EDIT: I’ve just tried compiling a bit of one of my projects to DOCX, using KB’s new internal converter, and as far as I can see at a quick look, AGP is correctly there with its italics, semibold, etc., Margin comments have come across properly, but this text has no footnotes … I should try putting in a couple of footnotes.

[gr]

Yeah, my only issue at this point is that conversion to docx seems to use a postscript name for this font rather than its proper name and that messes things up down the road (in InDesign). RTF does work for me as a workaround.

I have the recommended enhanced converters for Word enabled. So, the problem may be down to the java converter.

[xiamenese]

@gr

Yeah, my only issue at this point is that conversion to docx seems to use a postscript name for this font rather than its proper name and that messes things up down the road (in InDesign). RTF does work for me as a workaround.

I have the recommended enhanced converters for Word enabled. So, the problem may be down to the java converter.

Try switching the Java converter off and let KB’s internal exporter do the work. The only problem I’ve identified using it is that Word doesn’t like image names with spaces in them. Keith identified that from stuff I sent him, and I understand he’s got a solution ready for the next update.

I hope he’s picked up on this thread.

Mark

[gr]

I think if you turn off the Java converter what you are getting is an RTF-based .doc file. That is to say, you get the same thing as when you compile to .rtf except it is wrapped in a .doc wrapper. So it makes sense that that would work – though as far as that goes, I could just as easily compile to RTF instead as my workaround.

[xiamenese]

From what KB posted earlier this year, he has been working on his own DOCX converter, not RTF in a DOC wrapper. I haven’t got time to check for the thread now, but I’ll do so later.

Mark

[gr]

The Scriv preference dialog, when you switch off the enhanced converter, pretty much says that Scriv will then revert to the “pigs in a blanket” strategy. So, I inferred from that. The new way must still be coming down the pike (and if there is a beta out there, I am not running it).

Greg