I’ve been pondering how Scrivener might be made to bring a compiled & edited document back in, splitting it into it’s original documents and maybe even taking snapshots before replacing the original text with the edited words for that binder document.
What if there were a compile option that added a marker at the beginning of each binder document, so that on re-import, it could identify the text that followed at belonging to that original document? It could, in theory, be invisible, but I’d even suggest that it be right there, perhaps next to a document title or something. These would be kind of like (or exactly like) xml tags, bracketing the parts of the document that needed to be re-imported, vs the stuff that’s generated from binder positions (like document titles, Chapter 3, etc…).
I know this is a monster of a feature request, but I’m sure it would enhance a lot of people’s flows if it’s possible/practical; being able to accept/reject changes from an editor/first reader/thesis advisor professor whateveryoucallem in Word and then re-import the slightly messy, but complete text for further processing in Scrivener would be quite nice. The recipient would have to agree that they understand the purpose of the tags, and it would need to be crystal clear that the feature has been turned on/off from the very first page, to avoid leaving those tags in the final draft, but I think that extra clutter would be fine by most people’s standards.
Once I have a decent second draft I’m happy to send to a few friends for review, I compile and send out a Word file. Friends annotate, so from that point on I either have to switch to Word or manually make the edits with both apps open. The above system, provided it can handle Word annotations, would be brilliant.
What would be cool is if the folder sync feature could generate a Word master document, which if you are unfamiliar, makes its outliner act a little bit like a way clumsier Scrivenings. You can insert file links into the outline that display the contents of each file in one master file as though you were editing a single document. Changes made in these documents are made to the original files. All very fancy, and it would make it so your editor could open one file at the top and all of the individual section based files for Folder Sync would be updated as they made changes. Then you sync the folder and everything is peachy.
Unfortunately, making a master document outline isn’t something our .docx generators can handle—plus I don’t know how well that feature works in a portable fashion. If the document links require absolute paths, it probably wouldn’t work for this purpose.
But at any rate, the main problem with this idea is how volatile the separators would be. It would require everyone to be careful about not deleting any of them or changing them (which would also require great care when using global search and replace), and invisible separators would make that even worse as you might overwrite them without realising it, and some word processors might discard them entirely.
Indeed. In fact, I started writing just such a feature a couple of years ago, and it soon became apparent how many factors it would have to attempt to take into consideration.
If you included titles and chapter numbers, for instance, the import feature would need some way of knowing what was a title and chapter number and should thus be ignored.
You’ve also got the problem that if you compile using different formatting, then when you bring it back in all your formatting will be destroyed, using the compiled formatting instead. There are so many factors the user would have to consider when compiling in the first place that it would lead to many frustrated users and support questions.
Then there’s formatting that exists in Scrivener that would be lost unless odd tags were put in - Preserve Formatting, Scrivener links and suchlike.
I conveniently ignored the user support nightmare scenario, but now I can just imagine you pulling your hair out trying to support this feature with the limitations that RTF would impose on it’s implementation.
If only there were a simpler “scrivener for editors” that imported and exported Draft folders (& front-matter), but created a semi-editable view that closely resembled the compile output, preserving the underlying structure while allowing them to mark up the text and edit it… That should be easy, shouldn’t it?
