Importing documents with footnotes into Scrivener

Our Tutorial is quite categorical on this point: when importing RTF or Word documents with footnotes, annotations, images and the like, these attributes get inevitably lost. It also explains why: “This is a limitation of the standard Cocoa OS X text importers.”

That is a pity. Because one the collateral benefits of Scrivener’s project orientation is that it makes it possible both to clean up and to rationalize the labyrinth of maps and documents in the finder, and to give new life to semi-forgotten writings of the past. Documents which until now have led an independent or autonomous life in one of its remote and rarely visited corners, can now be grouped together in one project, and be effectively studied in their relationships.

And that’s indeed what I have been doing in the past few weeks. But unfortunately quite a lot of my old (Word) documents have footnotes, and therefore can’t be imported into a Scrivener project without serious damage; which of course I want to avoid.

Is what I want simply not possible, period, or does there exist perhaps some ingenious workaround? And what exactly should change in order to make it possible?

On this, I have to direct you here:

bugreport.apple.com

Please do register and ask Apple for support for RTF footnotes and images in their attributed string methods. They prioritise based on volume of requests, I believe, so the more that ask, the better. I don’t know what is in store for Leopard, but each release has seen significant improvements in the text system (tables and bullet points came “for free” in the Cocoa text system only with Tiger, for instance), so we can always hope.

To give you a brief explanation of why this is not possible for me to implement (or rather, Why I Won’t Spend A Year Of My Life Doing It, :slight_smile: )… First take a look here:

biblioscape.com/rtf15_spec.htm#Heading57

That is the RTF format for footnotes. If you delve into that, you will see that there are all sorts of settings and numerous other tags from throughout the RTF syntax that can be included. Now, it is relatively straightforward to add footnotes support to export: I use the normal RTF exporting methods from Cocoa but insert certain unique temporary tags that tell me where the footnotes should go, then I load the RTF file as plain text. I take the footnotes themselves and convert those to RTF separately (using the Cocoa methods again), then I insert them into the plain text RTF stream, replacing the placeholder tags and adding the necessary RTF syntax that says that this chunk of text is a footnote. Well, actually it’s a tiny bit more complicated than that, but that is the crux of it.

Now, going the other ways is more difficult. Whereas with export I can still use Cocoa’s RTF exporters to do most of the work for me and then just modify the generated file with just the bare minimum RTF markers, for import I would have to parse the actual RTF myself. Take a look at the RTF page I referenced above and see how easy you think that would be. :slight_smile: It would take months. The guys at Nisus and Mellel can do that because they have teams and they are working on dedicated word processors. But aside from the big word processors, no other Cocoa programs I know of can even export footnotes, let alone import them.

And then consider this: I could spend months implementing something like this only to find that Apple add it to their text system with the next OS release. Besides which, Scrivener is not intended to have all the bells and whistles of a word processor.

So this is why I ask you to go and register your request with Apple. If they add it to their text system, then everyone will be happy. :slight_smile:

All the best,
Keith

This is likely not the sort of answer you were looking for, but this is one of my big philosophical problems with closed, poorly designed document formats like word (and to a lesser extent, RTF). You get trapped into a particular application simply because that is what you used to use.

More open and well-designed formats allow you to import and export between applications more easily and with less loss of data.

It’s not an ideal solution, but this was part of my motivation with MultiMarkdown. It takes a little effort to tweak the formatting, but it is fairly straightforward for me to take a lot of my old Word files from college and convert them to plain text in MMD format. I can keep my bibliographical information (and convert to BibTeX for more flexibility), and can reformat my document in a variety of ways.

I guess my main point is to be very careful about which applications you use to archive important data. The only guarantee is that things will change over time, and by using an open format, you increase your chances of retaining access to your data in 5, 10, 20 years. (Fortunately I converted all of my old MacWrite documents a few years back, because that is hard to do now. :wink:

Does Word really have no way at all to “flatten” footnotes like Scrivener does with its own footnotes? Do you know much in the way of VB? If not, perhaps you could search the `net for something on this? There are a lot of Word macros out there (do they work on a Mac, though?) and surely somebody has run into this problem and wanted to extract footnotes.

Word is a mess, no doubt, but its simply gargantuan user base in conjunction with a fairly powerful scripting engine generally means there is a way to do nearly anything you need.

If there is nothing, but Word has a way to turn footnotes into text equivalents, let me know, I might be able to create something for you that will convert text footnotes to Scrivener footnotes upon import.

Taking bulk documents from a proprietary system into another, or an open format is always a big task. A lot of modern day apps are getting better at supporting open formats, or allowing some form of export that is useful – but a lot of old class “capitalist” based software such as Word remain resolutely difficult, because it is in their best business interest to lock customers into using their software forever.