Another approach to handling the matter of paragraph delineation is to use one of Scrivener’s tools for spreading apart paragraphs (refer to the attached project for a working sample):
-
In the Transformations pane of the Format designer, set Convert to plain text: Paragraph spacing.
Now at this point, if the sort of paragraph formatting you prefer to write with uses a small amount of spacing between paragraphs (anything over half a line height will do), then that might be the only adjustment you need. But if you prefer indents to mark paragraphs in the editor, then you’ll need to take an additional step.
-
In Section Layouts, adjust the layout(s) used to format body text. At the bottom of the “Formatting” tab, enable Override text and notes formatting.
-
Use the paragraph spacing tool in the mock editor to add at least one empty line between paragraphs. (Note that since the writing of this original post, all of the Markdown-based compile formats have this formatting applied already, so all you need to do is switch the override setting on for each layout that needs it.)
So with this adjustment we are using Scrivener’s rich text foundation to transform the formatting of the document, specifically targeting those areas that contain body text paragraphs, and then telling the engine to convert that visual formatting into literal whitespace in the plain-text output.
We can thus have sections of the text blocked out as being protected from that transformation. In the provided example project, you will find a “Table” section type, with a simple pipe table example in the binder. The way the compiler is set up is to leave Table type documents alone—simply output them as-is.
Another example I provided is found in the document called “section one”, toward the top of the file. We have here a simple definition list structure that we would not want to be pulled apart by line spreading. While at first glance this may look like it will be a problem from the editor’s point of view, if you compile you’ll note the def list comes out properly formatted. What’s going on here? If you go back into the editor and check the Format Bar, you’ll note that these paragraphs have been styled. The style is doing nothing special other than making them look a little prettier in the editor, which is mostly cosmetic save for where they insert a little strategic whitespace between elements, whitespace that will become literal whitespace where needed. But more importantly the fact that they are styled at all means they will not inherit Section Layout formatting. Their lines will not be broken apart.
So that gives you two different tools to override paragraph spreading: Type-based and text level Style overrides.
Likewise the “Metadata” document will have its formatting left alone given its special stature as being somewhat aloof from the output. (And that is also why its placeholder expansion isn’t quite the same; as I understand it this document is basically removed from the compiler internally and only added later on. We only recently got other types of document placeholders working within it. The word count placeholder might be an oversight, or it might be technically difficult to work in.)
Replacements cannot have that kind of specificity—clever use of regular expressions aside—they target the whole output, whereas formatting can be surgically applied and overruled as needed, and so generally that is the approach I would advise.
It does have its weaknesses. Say you wrote your pipe table using your normal paragraph formatting that has a cosmetic empty line between paragraphs and just let it be. Well Scrivener damage the table in that case. It does require you to think a little bit about what a document looks like, since its cosmetics will impact its structure—and while you may not like the double-return paragraph look cosmetically, you may not want to dive that deep in the muddy waters of formatting == structure. 