Footnotes missing when compiling into PDF

Hi there,

I experience an odd compile output from Scrivener 3 on Windows 10.

I wrote a little book on history, with a total of 159 linked footnotes (on the page). When I compile it to make a PDF (whatever the chosen format), the output is neat but takes randomly 10 to 15 of my footnotes out. On the missing ones, I get a broken(?) link instead (which looks like: scrivcmt://DCD60A05-etc. in the lower left corner of my pdf).
I tweaked in what I think is every possible way:
-It is not due to the length of the missing footnotes (as some of the deleted ones are no more than 3-words long)
-There is no special character or link (html or else) in any of my notes (just plain text)
-The font and size I used is the same all over
-I tried to play a bit around with the Compile footnote options, to no avail (with the exception of sometimes seeing 2-3 footnotes being accepted back, but not the total)
-Going from linked footnotes to inline footnotes does not change anything
-Deleting and rewriting the missing footnotes does not change anything either

As weird as it seems, when I transform my linked footnotes into endnotes, all the 159 are present at the end of the PDF.
When I compile it into an epub 2, the footnotes are complete as well.

So the issues does reside in the linked footnotes output when compiled into PDF.

Did anyone experience some similar issue (as I did see some related topics in the previous posts, but if close, not quite like it)? And if anyone did, what may be the solution?

Thanks in advance!


Since it sounds like it would take a very specific set of conditions in order to see this, what would work best for us is to provide a sample. This could be as simple as one single document that demonstrates both a working and broken footnote, rather than entire project.

Most curious to me is that this problem also happens with inline footnotes, which makes very little sense since the “scrivcmt” hyperlink being exposed like that would have no business being anywhere near an inline footnote. It would be as unexpected as finding an image instead of a footnote, they are completely different kinds of technology internally. So, something very strange is going on.

  1. Use File â–¸ Save As... to create a throw-away copy of the project in a temp location like Downloads.
  2. Strip out everything from the binder except for one or two documents that demonstrate the working and failing cases. Strip out any text not necessary for the test.
  3. Empty the trash.
  4. Use File â–¸ Back Up â–¸ Back Up To... to create a zip compressed copy, and drag that into the response field here to upload it.

If you prefer, you can also send it to me in a private message (click my avatar and then the big Message button).

JB Tryout [2022_05_26_14_24_03].zip (318.0 KB)
Thanks for your prompt answer. I did as told and send you hereby a version with inline footnotes (the text language is French, but I guess it does not matter much).
You will note that 2 of my footnotes (out of 19) are missing, replaced by <$FM> in the compiled PDF, with the “scrivcmt” link mentioned above.
I hope this may help. Please do not hesitate to ask me for further details, should they be needed.
Thanks in advance!

Just as a diagnostic reference, this seems to be fine on Scrivener for Mac.

JB (50.0 KB)

Many thanks! I can easily see it happen, and have found that it seems to be a problem with where the footnote marker falls on the page. I can’t say why, but if you try cutting the footnote starting with “Un équipage apeuré vendra…” and paste it somewhere toward the beginning of paragraph it was attached to, rather than the end, it shows up fine.

In searching through known bugs, I see a much more drastic version of this bug that we found a while back, so this will be very useful to see a case where there is no obvious reason as to why the footnote breaks. I will add this data to the report.

In the meanwhile, it is easy to work around by compiling to the word processor format of your choice and printing to PDF from there.

For reference, the similar report.

I can’t see the errors on a Mac. Wondered if they occur around footnotes that have double punctuation, such as the full stop and comma of this example:

Au début, nos officiers ne voulurent prendre aucun risque, mais ils finirent par croire que cette histoire avait été inventée de toutes pièces par un Anglais qui souhaitait acheter notre vaisseau à très bon compteUn équipage apeuré vendra son vaisseau à très bon marché, pour regagner son pays par ses propres moyens. C’est sans doute là-dessus qu’a compté un commerçant local., et nous choisîmes de sortir.

Well this is a bug specific to the Windows version, testing on the Mac wouldn’t tell us much; I don’t even know if it uses the internal mechanism they are using to mark footnotes temporarily and then later laying them out.

As noted above, the content of the note or its surroundings don’t seem to matter. I can trigger it just by moving the footnote (and subsequently its marker in the output) down far enough on the page, and it goes away when moving it back up. There is a clear point where it triggers, depending upon horizontal positioning within the page.

1 Like


Many thanks for the many feedbacks, which all seem to work apparently.

On my side, I have tried to export my work on a Scrivener session on Mac. As a consequence, all my footnotes are there. So I guess this indeed has to do with Windows. The exact reason does escape to me though, as other format (besides PDF) do work fine.

As to moving the missing footnotes in the paragraph, it does work as well indeed. Yet it does impair the meaning I intend to give to the comments and explanations I put in the footnotes (which looses all its sense if the marker is put too early or to late in the text).

In any case, thanks everyone for the very useful help on my case.

All the best,


Unlike every other compile format in Scrivener, PDF is the one format we do actually have code to “present” a page layout. Drawing the text on each page isn’t something we get too detailed about, most of it is up to the PDF generator, but we do add the page header and footer, and footnotes are one of the few things we have more detailed control over.

So this bug is extremely specific to that layout code, what determines if footnotes all fit on a single page, and if not, how they should be wrapped to the next page, and if the addition of footnotes to a page will cause footnotes at the very bottom of the page to end up being moved to the next page because the space it would take to print the footnote would hide the very text its marker is found within—messy stuff like that!

With every other format we don’t have to worry one bit about it and just print footnote syntax, or something that acts a certain way (like HTML linked text).

As to moving the missing footnotes in the paragraph, it does work as well indeed. Yet it does impair the meaning I intend to give to the comments and explanations I put in the footnotes (which looses all its sense if the marker is put too early or to late in the text).

Oh of course. I was pointing out where the bug was, not suggesting editing the marker to be in the wrong spot! :smiley: That would be a very fragile solution, as any edit prior to that point in the document might move the marker back into the “dead zone” or other markers. Indeed it would be very labour intensive to have to proof these every single time substantial changes are made.

As noted, the real workaround is to avoid the PDF generator in Scrivener for anything important (which I would advise any way on general principle, not only as a way to avoid a single bug) and use another. It’s really only a proofing tool—though sadly with this bug, not even very good for that if you need footnotes.

This is not merely a fluke (bug) specific to PDF compile. It happens to me for “Print” as well. Additionally, when using Kindle, it actually repeats footnotes. I have 43 footnotes so far. When I compile with Kindle, I end up with 48. I cannot afford to have this huge mistake in my final draft so I’m going to have to search for another software that is much more reliable. I cannot spend months on a project in here and end up having to re-do all of it because my footnotes are missing or repeated. This is a major part of my non-fiction work.

Print, PDF, it’s all the same thing by and large. One gets sent to your print driver, the other to your disk.

As for Kindle, I would suggest opening a separate bug report with specifics on how to reproduce this issue. Whatever you are seeing is not going to have anything at all to do with a PDF layout bug. My guess is that there is some condition that could be easily avoided, that would help us fix it. But none of that can happen without a report. I’ve never seen nor heard of that happening.