Hi Sonia,
I’m very sorry to hear that you have run into this problem. Over the past couple of years, we’ve had a handful of reports of this happening, but I’ve never been able to get to the bottom of it. Let me explain how anchored footnotes are saved so that you can have some understanding of how the problem might arise, and also of how the code I have implemented for the next version should at least avoid this issue in the future:
A text file is saved inside a .scriv project in the RTF format. A .scriv file is really just a bundle - a folder - of other files that looks like a regular file in the Finder. Each text document in a project is saved as a separate RTF file inside the project. Inspector comments and footnotes, however, are not saved in the RTF file, but in a separate .links text file. Each footnote has two main pieces of information associated with it: the footnote text, and the range of the text with which it is associated.
For instance, suppose you had the following text, with the square brackets indicating an anchor point for a footnote:
This is some text followed by a footnote.[*] More text.
The “range” of this footnote would be {41, 1}, because the asterisk associated with it is the 42nd letter in the text (it starts at index 41 and is 1 letter long).
So, the .links file saves information telling Scrivener the text of the footnote, and the fact that it should be associated with one letter at position 41 in the text.
This is generally a solid way of saving this information. However, if the underlying RTF file is somehow changed “behind Scrivener’s back”, as it were, then it the anchors could go out of sync. In the above example, suppose you peered inside the .scriv project (which you could do, by ctrl-clicking on it and using “Show Package Contents”), located the RTF file and opened it in a word processor, and then snipped out any one of the letters before the asterisk. Now, when you opened the Scrivener project again, the asterisk is no longer at position 41, but at position 40 instead. Scrivener’s .links file does’t know that, though, so it places the anchor at position 41 - one letter after the asterisk.
So, this is what is going on. I’m not suggesting that you have dug around inside the .scriv project, of course, but something has somehow changed the RTF file without Scrivener knowing about it. There are a couple of potential causes of this:
-
If it were only a letter or two off, I would guess that a bad character in the RTF hadn’t survived saving and reopening - this can happen when text is pasted in from elsewhere and has gremlin characters. You say that everything is a line or more off, though, so this is unlikely to be the case.
-
A more likely explanation is syncing gone wrong: do you store this project on Dropbox, or sync it between computers in some other way? If so, I would guess that either you have opened the project before it has been fully synced, or something has gone wrong with the sync process, so that the .links file and .rtf files were left out of sync.
To avoid this in the future, for the next update I not only save the range of text associated with the footnote, but the text itself. So, if a footnote is associated with an asterisk, Scrivener stores the fact that it is associated with an asterisk. On re-opening the text, Scrivener first checks the saved range, then checks that the text at that spot matches what it was expecting. If not, it scans around for the nearest matching text and applies the footnote there. This should fix most situations where things get out of whack.
That said, if you are syncing between computers, it will still be important that you ensure things are fully synced before trying to open a project. I’d definitely be interested to hear whether or not this could have been the cause for you.
Thanks and all the best,
Keith
