I have an odd, and probably picayune, question. When compiling to the “Manuscript” formats (or formats that I have saved based on Manuscript), the compiler changes the font of the footnote number to a different font from the footnote text. In my version, I get a sans serif font for the footnote number (in superscript), a space, and then the text in the serif font I have chosen.
I have looked at the Manual, searching under footnote and fonts and compile, and can’t find how to change the font of the footnote number. I am compiling to .docx, but I get the same result in all word processing formats.
The picayune part is that I need to submit my final documents in Word, and it is difficult to change the font of the footnote number; it basically has to be done note by note (and my documents often after 50-100 notes) If unchanged, the combination of fonts is slightly jarring.
Is there any way to change the font of the superscripted footnote number?
Thanks in advance.
The footnote number and text should compile with the same font by default.
I am not at a Mac right now to be able to share a screenshot, but during compile, there is an option, IIRC, to override the font used for footnotes. From memory, you need to edit the compile format, select the tab that controls footnotes, and then make sure that the override font setting is not activated / causing a conflict. Have you checked that setting? Perhaps someone else reading this thread could add a screenshot to help…
Here’s a screenshot of the problem, taken from the complied document (in Word):
The footnote numbers are in Helvetica, which I have not chosen. The footnote text is in Equity (a speciality font I use).
Here’s my footnote settings in the compliler – they seem to be working for text, but not for the footnote number itself:
As a test, does it compile correctly if you select a different / more standard font or if you turn off the option to superscript the markers? It might be the that font you are using is causing the issue.
Slàinte mhòr.
EDIT: the Scrivener project attached compiles to .docx with the footnotes correctly using Times New Roman throughout (or at least that is what I see when I open the compiled file in Pages: I don’t have Word). If you change the font to Equity, does it still compile okay?
EDIT 2: Pages has an option under Format > Font > Replace Fonts to change the fonts in a file globally. Could you open the problem file in Pages and simply change Helvetica to Equity (or are you using Helvetica elsewhere)? Does Word have a similar function?
JoRo:
The problem may be deeper. When I open up your file (thanks!) and just compile it, the same problem occurs. Text in the default font (Times Roman in your case), and note numbers in Helvetica. Here’s a screen shot:
Poking around, it appears that Word has a “footnote reference” style. That style is not invoked/left blank in the compilied document. When I change the style in Word, the font changes, but since there is nothing in the style after compile, I have to change each footnote individually, and since I often have hundreds of footnotes, that’s a pain.
Any other ideas?
BAM
Perhaps a switch in the converter used will make a difference.
That said, the sample file opens in Pages with the right font info (at least it does on my two Macs), so perhaps the issue is with Word rather than Scrivener.
Problem somewhat resolved, but not the way you suggested (and maybe not for long). I had already turned on the enhanced converters. Just to test, I turned them off. Bingo: no more font problem with the notes.
But only with the .docx converter. When using .rtf (and other word processing converters), the same font problem occurs whether the enhanced converters are installed or not.
So I get the result I want (no mismatch) if I convert to .docx using the old un-enhanced converters. I get mismatched fonts on footnote numbers on .docx using the new, enhanced converters, and when using any other converter (such as .rtf) regardless of the converter selected.
The idea is to turn off the old “enhanced converters” in order to use the new in-house .docx converters instead, which seems to have worked for you at least to some extent.