<$include: ... > not working

When compiling to Ebook, I want some documents from a different Scrivener project to be included. However, it is not working.

When I test it with a document outside Scrivener, it works:
<$include:/Users/MyUserName/Books/Text.txt>

This, however (path copied using “Copy Document as External Link”), does not work:
<$include:/Users/MyUserName/Books/Text.scriv?id=2FA87B43-7A04-4DAF-8F48-1A4AE93C6ADD>

Am I doing something wrong or is it not possible?

The issue is that the link is actually pointing to a folder. Scrivener keeps the body text, the synopsis, and any other metadata in an internal folder labeled with the unique ID that you see. Unfortunately, that means that when the Compile command follows the link it finds something that it’s not able to use.

I’m not sure if this is fixable. It would be technically possible to include a full link to the file itself, but I don’t recommend that as you’d need to poke around in the source project directly. But one alternative might be to sync the source project to an external folder, and then point the Include command to files in the external folder.

I assume the reason why you want to do this is that you have boilerplate text that you want to keep consistent across projects? If it rarely changes, another way to do that would be with a project template. However, a change to the template won’t affect existing projects, only new ones.

Katherine

Thank you! This worked.

Using an application like Path Finder, one just needs to right-click the Scrivener file, choose Show Package Contents, navigate to Files/Data, find the document and copy its path.

It then should look like this:
<$include:/Users/MyUserName/Books/Text.scriv/Files/Data/2FA87B43-7A04-4DAF-8F48-1A4AE93C6ADD/content.rtf>

Yes, that works. The reason why I didn’t explain how to do it is that it’s unsupported. Poking around in a Scrivener project with any tool other than Scrivener itself has the potential to corrupt the project and is entirely at your own risk.

Katherine

Of course, once one sees how it goes, one can infer the correct path from the path given by “Copy Document as External Link"), so no poking around really needed going forward.

Such cross-linking does seem rather fragile, though — subject to breakage from common Finder operations — moving or renaming projects, changing names of containing folders, etc.

gr

Correct.

From the copied link, one just needs to remove “x-scrivener-item://”, replace “?id=” with “/” and add “/content.rtf” to the end.