Retaining links within document when copying across projects

I have a large Scrivener project (a notes Hub) which holds many hundreds of my research notes. These notes are internally linked to other notes within the same Scrivener project. I now need to copy one of these notes - which has about 35 internal links - to a new Scrivener document (new project) for prose development.

Is there a way to copy this note across Scrivener projects in a way which will retain the links? I have tried cutting and pasting, and also dragging. The drag seems to copy the links (highlights the same key words) but I get a `Document link not found’ error when I click. I had assumed, I suppose, that internal doc links were the same as note URL.

I hope this isn’t a fatal error on my part: is there a way around this apart from opening the links in the original document, revealing them in the Binder and then copying the genuine URL?

Thanks

[Windows version screenshots]

I think that in order for what you described to work, you would have needed to rather link (and now would need to convert/relink) your documents using

or
image

(Different names, same function.)
. . . . . . . .

That creates a link that opens the project containing the desired document and takes you right to it.

If, when creating a link inside a project, you already know that you will at some point want it to link externally, the best course of action would be to use that method of linking right from the start.

  1. In the original project, compile the note to .docx with the ‘Convert document links to link back to Scrivener’ option selected
  2. In the new project, drag the .docx file into the binder (draft folder or research folder)
  3. The links in the new project should now open the documents in the original project

2 Likes

That’s a neat solution (much better than mine), but

why docx ?
Wouldn’t it be logical to retain the original format and rather compile to RTF ?

1 Like

You’re right. RTF also works. I just went for quick and easy without testing other formats. My bad. :face_with_spiral_eyes:

Meh! :wink:
So long as we get there.

1 Like

RTF was last updated by Microsoft in 2008, so I avoid using it whenever possible. It’s short in terms of modern features and functionality while still being a security risk (this link being just one example).

Know .docx is far from perfect, but it’s à la mode and offers greater reliability and compatibility overall.

I see.
My point, though, was that since Scrivener has all of its project files in RTF, and the compile is done with the intention of importing it to another project, might as well avoid the double conversion.
If any problem should arise of doing it one way or the other: that I don’t know.

1 Like

Understood. Good to have options.

EDIT: Compiling to RTF on macOS nearly always ends up with ‘broken’ files (headers and footers missing, for example), so I have become habituated to using .docx for compatibility reasons. Whether it makes a material difference in this case for the OP, only the OP can know. But in my experience, .docx is preferable.

1 Like

Many thanks - this is just what I was hoping for and it will save me an awful lot of time. This is just the first time I realised the issue - the notes Hub (for an history of medicine project) has been under construction for 5 or 6 years so there are many more times in the writing up when it will happen.

Edit: just tried it. Worked like a charm - hugely relieved …!

Many thanks again.

2 Likes

Good to hear that it works for you.

All the best with your work, research, and writing

Sobs

If compiling to RTF gives bad results, please give us the details so we can fix it. As @Vincent_Vincent said, RTF is Scrivener’s native format, so it should be the most reliable output format.

2 Likes

I think Scrivener can compile to RTF just fine in and of itself. Issues rise with compatibility with other apps opening those RTF compiles.

In my experience .docx compiles are more reliable and more compatible with more apps, so I have become habituated to using .docx if I need to share work in a word-processing format (rather than PDF, Markdown, etc). It’s a modern, regularly updated and supported format. RTF is an old and minimal interchange format, so it’s no surprise that it can do less than .docx and quickly runs into compatibility problems. If users only need bold, italics, and underline, it’s fine. For anything more, it’s better to use a well-supported format, even if it is only used as an interchange compile, such as Scrivener → .docx → Pages.