I am using v2.7 on Mac OS X.
No matter what I do, or where I specify ‘Plain Text’, all the files that I create are .rtf formatted. It’s annoying! I want plain text files!
Can someone please help me to convert all the existing files in the project I’m working on to plain text, and tell me how to setup Scrivener so that all the files I create are, from now on, plain text?
Thank you in advance.
Scrivener stores all your documents as .rtf files. When you compile the project then you can select plain text (.txt) as an output. Compiling will put all (your selected) documents together and do whatever conversion is required, which in your case would be down-grading them to plain text.
Then I’m confused! In the general preferences pane of Scrivener, the Scratch Pad default format mentions .rtfd, .rtf, and plain text files (I presume .txt). To what are those referring then?
The reason I want plain text for the scrivener project files, rather than .rtf, is that I am storing my Scrivener project in a source code control system (git). It’s working really nicely and I’m very pleased with it. Except that .rtf files are a pain to diff. Plain text files are not.
That’s a different requirement to what I want when I compile the project. Then the project might be output as a web page, Word, Libreoffice, or a PDF document. Certainly not as a plain text file.
As KB has explained in another thread (the one on when Scrivener for iOS is due) the Scratchpad is a special case. It contains files that can be in rtf or plain text. However documents in projects (and therefore appearing in a project’s binder are all rtf).
Use of source control systems has been discussed at length in many threads here. What you might find useful entirely within Scrivener is Snapshots (Docments > Snapshots > … ) that provides a similar function to git and others but in a richly encoded document situation.
If you don’t need to store the whole project in your repository, you might want to explore the external folder sync feature, which I believe does support plain text.
Ah - I’m glad I’m not going nuts and I’ll dig around a bit deeper. I’m definitely going to check out the external sync option, which sounds exactly what I’m looking for…
Thanks for the help guys…
Just an fyi - the main reason I want source code control and merging functionality is that the project I’m working on has multiple authors. Using source code control means they can all branch and work on their own versions which can then be merged back into the main branch. It avoids the hell that is “track changes” in other well-known word processing packages 
… I don’t know if this is still true, with the latest project format change (last year), but I don’t think that you can successfully merge scrivener projects if people are creating new binder entries separately.
My (possibly out of date) understanding: Say you start with the “Blank” template and check that into Git. Then have 2 or more people check that project out. Author A creates a “Chapter 1” document and starts writing. Author B creates “Chapter 2”, but doesn’t write anything other than the binder title. Author 3 creates a document template folder and a template file, puts in some boilerplate text.
Author A’s chapter one goes into a folder on the file system named 1.rtf the in .scriv folder’s Files/Docs folder. The binder’s xml file uses “Chapter 1” as the label in the binder, and associates that xml node to 1.rtf.
Author B’s entry in the binder doesn’t create a file on the file system.
Author C’s character template folder also does not create a file system file, but the character sketch file does, and it’s file system name is… 1.rtf. The binder name “char sketch” is associated with 1.rtf
Now everybody checks in their changes, and you get a conflict with 1.rtf and the binder xml file, as you have two different entries in the binder associated with the same rtf file name, and the 1.rtf file fails to merge and can’t be resolved because it’s actually two different files’ contents.
Ooooo - I’m glad I posted my use case now! Great feedback - thanks!
So it seems I’m stuck with .rtf files. Okay, I can live with those, I think (hope).
I suppose the 1.rtf conflict can be avoided if I create the scenario of Author A and Editor A and B (my situation). In that case, Author A creates all the content, which Editor A and B can edit and comment upon. In other words, one person acts as the central server that can create content, the others are only allowed to edit the created content. In that use case, Git works, right?
I was wondering about filenames and why Scriveners Draft/ChapterA/Foobar gets named Files/Docs/1.rtf. Why not Files/Docs/ChapterA-Foobar.rtf, or possibly Files/Docs/ChapterA-Foobar-UniqId.rtf or some scheme where it’s easy to map created content outside of Scrivener itself AND ensure uniqueness?
Collaboration is an interesting topic, I think. I can’t be the only one working on a project with multiple contributors. How do other people handle that situation?
There are indeed others collaborating using Scrivener, me for one. While I can see that anyone using GitHub in the normal course of their work-life would be tempted to try to use it in relation to a Scrivener project, my feeling is that, given the structure of a Scrivener project it will introduce more problems than it will solve unless all the people involved are using Scrivener itself. The scenario you present
assumes that the edits will be done using some text editor, in which case they will not be integrated in the other associated files that form the .scriv, project, which will at a minimum cause the index file to become out of sync. Modifying internal files with other editing software is strongly cautioned against as the project can easily become corrupted.
And if all of you are using Scrivener for this purpose, from what you have said, it introduces other problems, including the .rtf format, as in your original post. Using “External folder sync” is one solution. The other, which I suspect most of us who work collaboratively use, is to put the active Scriv project in a shared Dropbox or Cubby folder. The key to success in that method is negotiating times for access to the project.
You might like to look at:
Mr X
fyi - all collaborators will be using Scrivener.
So the architecture I am going to try is putting project.scriv on Dropbox. I will give all collaborators full access to that. I am then going to configure everyone’s Scrivener to externally sync text files to a local git repository. That repository must then be pushed to our central GitHub repository. I can then pull any changes that the Editors make from there, merging them into my local git repository. Finally, I can then sync the merged text files with my instance of Scrivener.
That should work, right?
I wish you luck. It sounds overly complex to me, but it’s your decision.
Mr X
I know what you mean regarding complexity. But by using git, I can do a sort of “track changes” and decide exactly what edits I want to merge back into the original text.
No, Scrivener snapshots (which are a brilliant feature, BTW) are NOT similar to integration with project-wide source control. There’s a reason why some of us keep bringing source control integration up from time to time – done properly (and I can understand why L&L doesn’t want to invest the time in this) it could be a very valuable timesaver to particular types of workflow.
But as nice as snapshots are, they’re not the same, not even remotely, and it’s not helpful when people ask for X to tell them that Omega is almost the same thing when they’re not even in the same character set.
Honestly, you’re better off keeping Git out of it and using other features within Scrivener to mark the changed documents. Once you get familiar with how Scrivener works internally, you might be able to figure out how to make it work with Git, but trying to embrace it all at once is going to lead to situations where you lose work.
What happens when you rename the file in the Binder?
The whole point of the numeral.rtf naming scheme is that the filename on the disk stays the same regardless of the file’s name or location in the Binder.
Katherine
How many collaborators do you have, and how complex is the project?
In particular, Scrivener DOES NOT support simultaneous editing of a project on multiple systems. If you give all collaborators full access to the main project via Dropbox, you MUST ensure that simultaneous editing does not occur. Ignoring this requirement is extremely likely to lead to data corruption.
In my experience, the best way to manage multiple editors is to use a tool designed for collaborative editing. Both Word and Google Docs have put significant effort into these features, for example. Then appoint a Chief Editor to incorporate the group-edited components into Scrivener for assembly of the final output document.
Katherine
Aside from archiving, source control gives you the ability to branch and tag. For example, I could fork off a version of the project for the editors to work in, and integrate any or all of their changes back into the main branch when they’re done, perhaps tagging that integration as version 0.1. That ability is extremely powerful.
Anyway, I hear you regarding keeping things simple otherwise we might lose work. In fact, in a way, that’s already happened, as a sync of some text files lost some of the carriage returns and ruined some markdown - no big deal but a bit of a pain, nevertheless. Anyway, thanks for pointing out Snapshots - they’re nowhere near as capable as source code control, as has been said already, but we will integrate them into our methods.
Thanks again for the help.
I find it difficult to believe that a member of Scrivener support staff is advocating ‘other products’! Scrivener has a multitude of features over and above those products mentioned that make it absolutely essential for the project I’m working on. Not least the ability to split a large project into a number of smaller ones and then reintegrating those parts back into the larger project. That feature alone aids collaboration far more than those other products ever could.
You must be new here…
As a company, we understand that Scrivener does not necessarily offer every feature that every potential user might need. That’s by design. And we would rather send users to more appropriate tools than have them dissatisfied.
And having an attempt to use Scrivener for collaboration end in disaster because of editing and synchronization conflicts tends to make users VERY dissatisfied indeed.
I am certainly delighted to hear that Scrivener appears to meet your needs. I hope it continues to do so.
Katherine