Tried the 'view footnote numbers after compile' but none show in inspector

I’m working in a long nonfiction mss with hundreds of footnotes, treated as endnotes. After reading a print copy of the first draft, I’ve marked multiple notes that would be better treated elsewhere in the book and others I could just cut. I use the inspector to skip between notes already, but now it would be helpful to see the existing footnote numbers as they were in that printed draft.
I’ve followed the instructions to save the mss, then > View ▸ Text Editing ▸ Show Compiled Footnote Numbers in Inspector > Compile, but after three tries, I still don’t see the numbers in the inspector. I must be missing a trick or not turning something else on.
I took a screenshot of how my screen looks, following the instruction to turn on Show Compiled Footnote Numbers before compiling.
Many thanks for any advice –

Have you compiled since turning it on? I believe the numbers will only show up in the inspector once you have turned it on followed by compiling, which is necessary to establish the numbers that need to be displayed.

:slight_smile:
Mark

Hi Mark – Yes, I had the Scrivener Manual open on the screen as I did the process: save > turn on view footnote numbers > compile. Theoretically, when I return to the project screen, I should be seeing the numbers, but no soap.
FWIW, I also turned on the ‘prompt before updating footnote numbers’ at compile stage, and it didn’t prompt me to pause. Maybe becos’ I haven’t actually cut or moved any notes yet!
Laura

The fact that it isn’t asking whether to update the numbering is a clue. Have you opened the compiled file (and what type of file is it by the way?) and verified the footnotes are actually in the text as footnotes or endnotes? If the compiler doesn’t find any notes, then it will skip that question.

Something you could try as an experiment is to set your compile Format to something stock, like “Default”, which has most options disabled, using basic “RTF” as the Compile For type at the top. Then over in the General Options tab on the right, make sure footnote export is of course enabled. If that does work, then let us know what is different from your typical setup, and that.

2 Likes

Hi AmberV – I’m running Scrivener 3.4 on a MacMini running Sequoia 15.5.

Previous compiles in February and April properly produced all endnotes numbered sequentially 1,2,3 in both the body text and the endnotes, successfully exported to MS Word and printable.

In the first of yesterday’s efforts to compile explicitly to get the footnote numbers to show in the Inspector sidebar, I changed no settings except to Show Compiled Footnote Numbers in Inspector, compiled exactly as before in my project setup fonts etc. Not only did it not produce the numbers in the Inspector, notes are now numbered in Roman numerals in body and endnote section.

This persisted even when I changed the compile setting to Default Times as you suggested, when I manually changed the export of footnotes to a,b,c and when I manually changed it back to 1,2,3. And still no numerals of any species show in the Inspector even after saving and closing the project.

I can upload a version of the project called ‘sample’ if you would like to take a look at it, or park it somewhere and place a link here. It’s so frustrating that I’m now worse off than I was before tinkering and losing hours that I should be spending writing :disappointed_relieved:

changed_footnote_style_2025-06-01 at 5.44.41 AM

1 Like

The numbering or marking format shouldn’t matter to this feature. Scrivener won’t replicate the choice into the inspector (it will always be 1,2,3), but it shouldn’t inhibit counting even if you use something like a rotation of symbols.

I can upload a version of the project called ‘sample’ if you would like to take a look at it, or park it somewhere and place a link here.

That would probably help a lot! I can go through a dozen ideas in minutes and scour the project code itself rather than having to relay ideas back and forth. Feel free to send it privately if need be, you can click on my avatar and message from the popup. The forum has a mb limit, so links are fine if it’s too big.

2 Likes

Okay, I had a chance to play with the sample you sent. The first thing I checked was to see if it was a display problem, if maybe the numbers weren’t showing up for some reason but still being generated. They definitely are not, they are nowhere to be found in the places where they would be saved.

So the next thing I tried is a typical troubleshooting tactic, and that is to do half of what you normally do when the total malfunctions. In this case that means selecting half of the chapters and compiled only those—and in doing so, I got numbers! I tried the other half to see if maybe it was an issue with a bad footnote somewhere in the second half, breaking the whole process, but those generated as well so long as I didn’t include the first half.

Given how many footnotes you have, it seemed like it might be a problem of scale, that maybe the internal counter has a limitation that once exceeded causes it to fail. So I tested that theory in an isolated test project where I just spam duplicated test files until I had over 17,000 footnotes all successfully being counted when compiling. While you have a lot of footnotes, I don’t think you have that many!

So there is still something peculiar to the data that is causing this counter to fail, and I’m not sure that I can easily pin it down without debugging, which means it might be a bit before it can be looked at. It does seem there is a bug that you found here, though, and at least we have the means of isolating it with the test data—so thanks for that! I just wish I had a switch you could flip or something that would make it work in the meanwhile.

Partial compiling works, but that’s no good for this particular feature since doing so drops the numbers for the other half and starts over at 1 with wherever your selection starts.

Wow! And I thought the ants trying to get into the kitchen was bad… Well, glad this bug will be of help in the Greater Good.

What seems so strange is that it’s the same number of notes (around 1200 :grin:) as when I compiled in February and early April, so there must be something else in the project that’s triggered the weird behavior. If anything, I’ve been clearing out URL links from footnotes into a separate spreadsheet of data sources, so that’s not likely it. The project has 450 individual ‘sections’, as each letter is a separate document so I could shift them as new letters materialized, but that was true in the earlier iterations as well.

I’d be very grateful for y’all to pursue the solution. I do have a bit of a deadline problem in that the draft, with footnotes, is due to the editor on June 23rd. Having footnote numbers visible in the inspector was going to make assembling the appendices much simpler, although I suppose I can use the numbers from the printed April draft and tag the appendices manually as I write. But I will need reliable footnote numbers when compiling the draft for editing and layout.

If you could keep me posted on how the debugging progresses, that would be swell, with thanks for all your help!

1 Like

Well you always have the actual count of them in the compiled document. Maybe try using PDF to compile with, and use the File ▸ Import ▸ Research Files as Aliases... menu command to import it into the binder as a link. The idea here is you can then toss it into a split for referencing numbers, while writing the appendices in the others split—and since it is a link, you can compile updates to overwrite the target file directly, rather than trashing and re-importing over and over.

That’s exactly how I proof, once it gets to the point of needing to work against a mostly finalised copy. It’s quite convenient, just remember to click the refresh button in the footer bar for the PDF split after compiling an update, and if you need more than two splits, the Copyholder and editor history features almost always suffice (for me anyway).

1 Like