I am using Scrivener 3 for MacOS. I have numerous footnotes (60+) scattered throughout my historical fiction novel. Upon compiling for PDF, I am attempting to convert the footnotes into endnotes, thus supplying a glossary at the end of the back matter. It works just as I’d hoped, except for the fact that it only converts the footnotes up through number 38, leaving almost half of the footnotes missing. What’s going wrong here?
That sounds to me like a very specific problem that would require troubleshooting the content itself. What I would do is isolate the problem, since it happens at #38, you should be able to create a sample project with the footnote around the problem and send that to support, where we can take a look at the problem directly.
If you’d rather troubleshoot it yourself though, I would suggest retyping #39 from scratch and seeing if that helps. It could be some invalid character or something got inserted into the footnote field that is messing up the compiler.
If your references are sometimes pasted from online sources, that is a great way to get invisible, invalid characters in your text that can mess up your compile. If you are on Mac, the Zap Gremlins menu item can be very handy to clear such invisible character codes out of a bit of text.
Thanks for the information. I’m not familiar with the “Zap Gremlins” menu item. Is that a standard part of Scrivener, or some add-on?
Edit → Text Tidying → Zap Gremlins
(It’s part of Scrivener.)
I found the Zap Gremlins menu item, and performed it on the entire 100K+ word manuscript, and I still get the same issue. I guess I will take the piece of text that is causing the problem and use it for its own project and have someone take a look at it. Can I somehow upload that here for someone to examine it? Thanks.
oops. I just now saw the link above to support. Thanks.
If your footnotes are in the inspector, I do not believe that command will go into all of the footnote contents and zap gremlines. I’m pretty sure you would need to run it on the suspect footnote itself.
That aside, did deleting and then retyping the footnote not help?
The matter gets more and more mysterious as I probe into what might be happening.
First, I took the chapter in which the last compiling footnote appears, and compiled it alone (along with front and back matter). All of the chapter’s footnotes compile fine, even the ones in the chapter after the one in question.
So, I thought maybe there are just too many footnotes in the manuscript (I couldn’t imagine that really being a problem, but I am grasping at straws here). So I removed a bunch of them and recompiled. More showed up the endnotes, but I could see that it ended at exactly the same number of pages—452.
That seemed very odd, so I thought that somehow, I was hitting some kind of a page limit. Again, that didn’t seemed likely, but in order to further probe the problem, I thought if I changed the font size in the body text from 11 to 10 point, it would compile with far less pages, and perhaps all of the endnotes might compile. It did compile to just 390 pages, but the really odd thing is that now there are even LESS endnotes showing up than when it compiled with MORE pages! I am perplexed.
I think I may have just discovered the problem. I changed the font I have been using (Coelacanth, Regular) to a more vanilla typeface (New Times Roman) and now all the endnotes appear. Hmmmm. I love the typeface, and hate to give it up, but how could this be causing a problem?
Could it be that there is a character or some characters in your footnotes that aren’t provided in the Coelacanth font? Perhaps a letter with a diacritic? You can view all the characters in the font using the Applications: Font Book: View: Repertoire menu option. That may be worth investigating.
Or maybe you are hitting a place where a typeface in that family is called for, but you do not have it installed in your system. Such as the Italic typeface for that font. If you use italics in your text, it is not enough to have the Regular typeface of your preferred font installed. I am not sure this would result in the behavior you are seeing, but sometimes folks aren’t prepared for the fact that these separate typefaces are needed. (Because Word faked them out for so long.)
Font files can also get corrupted. (I am not sure how and have never had it happen to me, but one hears about such things.) There might even be an encoding problem with one of the typeface files of that open source font — one that may have been noted and fixed since you downloaded that font package.
While I was originally using a 5-year old version of the typeface, I found the most recent version, only 3 months old, and downloaded that. I removed the original version from Mac’s Fontbook, and then installed the newest version. I re-opened my project in Scrivener and made sure the typeface was still available and operating and that looked OK. I then re-compiled (with great hope!), but, alas, the exact problem surfaced.
Yes, the typeface is VERY complete, including something like 32 different font styles. It is a very professional-level font, with all the bells and whistles. As I was installing it via Mac’s Fontbook, I also took the opportunity to validate it, which I did, and everything checked out fine.
So, here is another question—could I possibly need to embed the font, and perhaps I need to do that in order for my POD to effectively print it the way I want? Can that be done in Scrivener when compiling to PDF, or does it automatically accomplish that?
Have you tried any other of the more extensive fonts besides Times New Roman? It really does sound to be an issue with that particular Coelacanth font, whatever it may be. If multiple fonts work while Coelacanth doesn’t, as I suspect may be the case, your problem will be closer to its solution.
Are you printing from a different device than the one where you created it? If so, you may need the font embedded, but I think that happens anyway if you Compile to pdf. It may not, however, if you export to Word and create the pdf from there.