If I understand correctly, this isn’t really so much of a workflow that is being proposed but a one time procedure to fix a formatting problem more efficiently in a different tool?
If so I think this is probably the best answer:
And the best way to ensure your document structure is maintained is to set up Heading 1 – 4 (or whatever depth you require) styles in the compiler. This is something that is a good idea to have anyway, as a stylesheet outline in your compiled file will work so much better in word processors, down the road. You’ll be able to insert a ToC with a single command, use the navigation tools they provide, etc. So what could be done now as a quick and dirty outline preservation tool could form the backbone of how your compile setup works down the way.
Setup Instructions...
What I would do is quite simple:
- Set up Section Types in
Project ▸ Project Settings...to include enough headings for the structure you have. Part, Chapter, Section, Subsection, etc. Use the second tab to have these hierarchically assigned. There is a walk-through on this in the interactive tutorial if it is new to you. - For this kind of task we don’t want the compiler to do much of anything at all, other than stick those headings in. We want the text to stay the way it is. So rather than adjusting one of the more elaborate Formats, make a simple new one with the
+button at the bottom of the left sidebar in the compile overview screen. - Click in the Styles pane and create however many heading styles you need. The naming convention is “Heading 1” for top level, “Heading 2” for the next below that, and so on. They can be either para or para+character, but it really doesn’t matter a whole lot, nor does how they look. They exist purely to make importing this file back into Scrivener better, later.
- Now go over to the Section Layouts pane and flush all of these examples out with the
-button on the top right, save for “Text Section with Heading”. Rename that to “H1”, and in the sample formatting area below, assign your “Heading 1” style to the Section Title sample text. - Click the
+button to create a new one, call it H2, and use the “Heading 2” style. - Repeat as necessary.
- Save the Format with a good name, and once you return to the compile overview window, click the
Assign Section Layouts...button to marry the concept of “Part” to “H1”, “Chapter” to “H2” and so forth.
You might be wondering why we don’t have such a setup for you, built-in, but you can probably see why that would be difficult. It’s really a problem with the whole rich text concept, with styles driving how such documents work. You’ll find the same exact issues in a word processor, where in some works Part needs to be Heading 1, while in others like an article, “Section” needs to be Heading 1. One-size-fits all document generation doesn’t really exist outside of the Markdown universe, where we simply declare heading depth directly rather than semantically or in an embellished way that forces their intent, with formatting.
Example files...
Here is a simple setup patterned after the above, that can illustrate what is going on, and it may even be of direct use to your project.
4-level-example.zip (4.0 KB)
To use it:
-
Open
Project ▸ Project Settings..., and in the Section Layout pane, click theImport...button and select the “4_level_schema.scrtypes” file from the zip.Note: the Export button might come in handy if you have stuff already set up here that you care about keeping.
-
In
File ▸ Compile...drag and drop the “four_level_outline.scrformat” file into the Format sidebar to import it. -
Now all you have to do is assign the Level 1–4 Section Types to H1–4 Layouts.
After the document has been modified externally, use File ▸ Import ▸ Import and Split..., with the split method set to Split using document’s outline structure, and Remove first lines of text when splitting by outline enabled. The heading structure created above will be converted back to a nested outline and the headings themselves stripped out of the text.
As for this:
And, talking of compiling, there is a setting somewhere to compile with each document marked so that that can be re-imported into the original project with documents automatically being allocated correctly…
Unfortunately that is not what it does. The most it does when you import it back into the project is transform the text markers into internal links. This is 100% a proofing tool. It is so you can proof a PDF or whatever and when you spot something that needs fixing, click a link to jump straight to it in your project. The links/markers are intentionally not removed when importing, so that you can proof in Scrivener. Thus that option would add a bunch of stuff you’d have to manually delete.
There is nothing, other than External Folder Sync, that routes external material between independent binder items. Doing this in a single flattened file would be difficult and prone to failure if markers are moved or removed accidentally.
Whatever the case, it is best to do this kind of thing early rather than later, and to get as much done as you can think of while in the word processor. Compiling and then importing with the intent to replace your original outline is pretty destructive, particularly the more you start using of Scrivener’s feature set. The only thing that survives this is the raw text and outline hierarchy. Labels, metadata, links, freeform corkboards… everything we might want to use Scrivener for at the outline level will be lost.