I’m posting here what I did to be able to get portion of documents from a Scrivener source to another one. Having been told it was possible, and then, it was not, I guess I think this topic needs some clarification.
First, I do not know if there is another easier way to do this… but if you know, please tell us.
OK, I was told by KB in the blog comments a few weeks ago that what I was trying to achieve will be feasible with Scrivener 3.
This is my basic needs and context: “… Using Scrivener mostly to prepare my teaching and training notes, I constantly reuse part of the information from other files. At the moment I just do an ugly “Copy-Paste” but would prefer to reference the source and be able “at compile” to import as text the reference. Any better idea how I can do that?”
KB answer was “As for reusing information, scrivener has a new placeholder tag. You can use this to include the text from other documents inside Scrivener, or to include the text of text files stored outside Scrivener, embedding it right into the text during Compile. So you should be able to do what you want there in 3.0.”
Let’s say that you are getting a link from a Scrivener file called FileSource.scriv
Then, you want to import only text from the file to a new document called FileDestination.scriv
From the FileSource.scriv you will use the function “Copy Document Link” and will give you a result like this: x-scrivener-item:///Users/YourUser/Dropbox/Apps/Scrivener/FileSource.scriv?id=E87AC320-8C71-4FA3-9B54-B8FB66515D01
In the FileDestination.scriv you will need to do this to import the content from the FileSource.scriv:
1- You must use the placeholder tag <$include> but do not use the \ sign before the tag
2- Then from the link you copied earlier, remove the scrivener app reference (“x-scrivener-item://”)
3- Use the scrivener file name as if it was a folder (Remove the extra char( “?id=”)
4- Use the UUID as a folder and add the rtf file it contains
5- You should have the final result like this: <$include:/Users/YourUser/Dropbox/Apps/Scrivener/FileSource.scriv/Files/Data/300BD8FA-398E-46B8-BAF8-A4B4E4941470/content.rtf>
One last thing… It would be nice to have a function that does all of this instead of having to do it manually.
Maybe it already exists?
Yeah about that, you might want to be careful when linking directly to internal data storage components in a file format. They are RTF files, and linking to them should be perfectly safe in the sense that it’s a passive read when you compile—but it’s still an internal storage component.
All right, here’s something you can try:
Put an inspector footnote into your source document, the one you’re linking to.
Compile the other project to RTF.
Obviously not the desired effect. Try throwing a block quote style on a paragraph and compiling again. There are all kinds of things that can go wrong by ripping the raw source data unprocessed like that. Scrivener has a lot of features that aren’t, strictly speaking, RTF—and it has a lot of features that depend heavily upon local data inside of the project format.
So by all means, Use At Your Own Risk—the simpler the better; it works in theory—but hopefully you can see why we don’t have any menu commands or knowledge base articles for doing that.
To come back to the original point: I think there was perhaps a misunderstanding over the initial question when that answer was given. The feature is strictly designed to:
Include from other items in the binder.
Or from RTF/TXT files on the disk—and by that we mean normal RTF files, not stuff buried inside of an applications package format.
The concept mentioned above is something I may have occasion to use.
I wonder if it would make a difference if you first compile the “filesource.scriv” to rtf or text, store it on the computer (vs dropbox) THEN proceed with the recommended process? Would this make the process work as intended?
Note that the post you’re responding to refers to an older version of Scrivener.
The key point is that the feature assumes that the included file is either in the current project or a standalone independent file. Whether it’s in the Dropbox folder or local shouldn’t matter, but having it inside a different Scrivener project is not supported.
If you compile to an RTF file, then the result is not a project, it’s an RTF file. So yes, the #include placeholder would work, but there would be no connection to the source project. If you needed to update the inclusion, you’d need to recompile.
I didn’t spell it out because the person I was responding to was already doing something we don’t recommend, and I could use their setup to illustrate where it can break in a manner they could test and see directly.
Basically the .rtf files Scrivener uses to store its data are likely not useful as stand-alone RTF files, because they store data within them using shorthand and bespoke mechanisms that only make sense within the project. For example:
An inspector footnote or comment is not a normal valid {\footnote ...} RTF command, but rather it is a hyperlink pointing to an essentially invalid protocol (outside of Scrivener), specifying a UUID, which in this case is the identity of the footnote data stored in a separate XML file. Open that .rtf file in Word and you’ll get a broken link. Inject it into another project that has no access to the original project’s structure or metadata, and you’ll get a broken link in the compiled output.
Any use of styles will be decoupled as styles are project-specific, and indeed their specific contextual usage is item-specific. I don’t even know how it would break if you try to inject styled text into another project without any conversion processing between two open projects (like you’d get on drag and drop between binders), but it most certainly would break.
So, none of that really has anything to do with an RTF file compiled from Scrivener, because the compiler is in part a mechanism designed to take all of this internal data and turn it into something that is specification-friendly. The weird hyperlink to a UUID is turned into a real footnote. An image link to the disk is read and embedded into the .rtf file as Base64 encoded data. The bespoke style markup that Scrivener uses to add stylesheets to a text engine completely oblivious to them is conformed to proper stylesheet commands that other word processors can read… etc.
