In fact Scrivener does not insert page breaks when compiling to Word (docx) as claimed everywhere in Scrivener’s user interface and documentation. There is also no extra paragraph.
That is correct, the technical formatting command that it inserts under most circumstances is a Section Break, not a pure/simple Page Break. I use the latter in common discussions to describe both, because on the surface they achieve very similar effects and that is how the software describes them.
It is possible to have Scrivener generate simple page breaks, but you would need to disable all features that require mid-document data changes like header/footer setups, front matter using different page numbering, and so on.
Scrivener’s procedure is equivalent to manually inserting a section break at the end of a paragraph in Word by a user.
So the problem that we have is that the toolkit itself handles things that way, given how it organises data in memory and then generates output from that structure. We would have to override how it handles text data at a fairly deep level to fix this. But yes, the details aside, the end result is as you describe: a user inserting a break incorrectly and then not fixing it.
On achieving best-practices output from Scrivener...
To sum up for me, Scrivener offers many possibilities for “formatting” (like section breaks or headers/footers) - but that they really should not be used at all…
100%! If I were a word processor user I would use one of these two routes:
-
I would stick with how I write currently, with Markdown in Scrivener, and use Pandoc to generate the DOCX/ODT file—which is enormously cleaner and better conforming to best practices and conventional behaviours (MultiMarkdown’s ODT isn’t bad either). That workflow is almost exactly like what I describe doing manually in the other thread: you design a document template and then Pandoc handles the creation of the raw styled formatting and injects it into the template for you, skipping the step of importing the text yourself.
So it’s a very clean, efficient and quite powerful workflow if you need a good word processing document. I do have some quibbles with how it works—and in some areas it feels like a WIP. For example I’d rather see proper image floats with dedicated captions rather than a “Caption” paragraph underneath an inline image, but one big advantage to using Markdown to write is that our documents get better as the years go by. Stuff that I wrote back in 2008, when Markdown was in its infancy with regards to complex documentation creation, creates much better documents now, without me having to change anything about the source.
The emphasis here is that Scrivener can produce well-formed documents right now, out of the box—and writing with Markdown is probably a whole lot less about writing with Markdown than you think it might be, considering how the compiler has an RTF to Markdown conversion engine built-in. Many wouldn’t even need to see much, if any, syntax in the editor. The user manual PDF for instance, which does a lot more formatting than native Scrivener can even dream of doing, is a Markdown project—but in most sections of the source project you probably wouldn’t even notice or realise that.
-
If I were to abandon Markdown for some unholy reason, and use rich text formatting as a basis for how I write in Scrivener, then I would do what you are saying. In fact when I started playing with this and creating a proof-of-concept some months ago, I created a compile format that very deliberately avoids as much of Scrivener’s formatting as possible. You can’t avoid all of it, but I got it down to the point where everything about the look and feel of the document could be overridden by the template I inject the compiled .odt file into. So that absolutely is the route I would take if I had to work this way. For me, what comes out of the compiler would look almost nothing like the final product, and would be intended more as raw data.
I wouldn’t though, because even that workflow has limitations that I do not have with Markdown, such as being unable to cross-reference to figures properly (with Scrivener the best you can do essentially boils down to using markup in the editor anyway, so… might as well just use a mature and broadly supported markup rather than something that only works in one tool and produces static text instead of field references and dynamic numbering).
…Which raises the question for me, why Scrivener offers possibilities that only lead to errors (or let’s say “weaknesses”) which one should avoid with procedures with further software.
It’s a good question. Why is it this way? Mainly because it has grown organically and gradually over the course of nearly 17 years now, most of which during that time it had no proper stylesheet support at all (true, the Windows version is younger than that, but it’s core design comes from that legacy). These kinds of brute force tactics I describe above are the only way to do most of these things if the output is oblivious to styles. While styles were finally implemented, they were really only implemented at a shallow level. They are applied to text, but not even by default in Section Layouts (owing to other design corners and Catch-22s). It was, you might say, a “phase one” implementation of stylesheet support.
It’s also worth bearing in mind that for many years this was all good enough, too. Most people were handing off a Courier or TNR manuscript and it’s okay for such documents to be technically sloppy. Publishing houses have piles of macros to fix author sloppiness because authors often have no clue how to use a word processor beyond typing—hitting tab to make indents, etc. But as more people are now doing their own design, or handing their work over to freelancers that may not have decades of helpful macros in their tool-chest, the importance of having a well-formed output is more relevant today than it was when Scrivener started out.
So yeah, if one is doing things the right way and wants a best-practices document, either of the methods I described above, are the best ways to use Scrivener, hands down. If you’re not doing thorough design or embarking on a collaborative or institutional workflow that requires well-formed documents, and are just hoping for the best (maybe even using PDF then)… then whatever. “WYSIWYG” works even if what you see is “wrong” from a best-practices standpoint. 
It works if all you are doing is opening the output in a word processor and using its better layout engine to create a superior PDF than what Scrivener can create natively.
These factors are probably why this is not more of an issue. Most of the people that would even notice Scrivener’s output are, like I say, in a workflow designed to strip out sloppiness anyway.
This does not mean we shouldn’t improve, but that is deep level overhaul territory for some point in the future.
