@Julia: Is there a setting somewhere that will do this for me automatically?
The answer is a bit complicated by the fact that it sounds like you are using Markdown to write, but instead of using Scrivener’s native Markdown-based output mechanisms, have chosen to use one of its RTF-based outputs. That’s perfectly fine to do—we have a checkbox that converts from MultiMarkdown to rich text for that reason—but it does imply a properly formatted Markdown text for the source.
The reason for there being no automatic “double every newline” checkbox is that this would quite often break documents. In your case it may have worked okay, but some Markdown syntax requires lines to be adjacent.
So that all said, I would definitely at least consider using Scrivener’s Markdown integration rather than rich text conversion, for a few reasons:
-
The conversion is… okay. For a novel I suppose it will do fine, but you will find it lacking if you’re writing non-fiction and have need of a wider array of formatting tools, such as block quotes, footnotes and so forth. It’s very simple, and lossy, because it basically converts Markdown to HTML, then converts that to RTF then converts that to whatever output format you chose—which in the case of ebooks, means converting the RTF back to Markdown (ha), which is then converted to HTML via MMD, and then piled on afterward with a bunch of macros to clutter up the HTML with RTF-based formatting additions! That’s kind of ridiculous when you think about it, particularly when you consider there are Markdown tools for generating clean ebooks in one single shot. When you consider all of the convoluted conversions you requested of the compiler, it’s a wonder only the paragraphs ended up getting mangled!
-
So, stepping away from that bowl of spaghetti, on the actual Markdown side of Scrivener you will either be using the MultiMarkdown or Pandoc engines to parse your text and ultimately generate the final output file directly, in one single and clean step, rather than Scrivener. Scrivener’s role becomes relegated to creating the Markdown file—a much simpler and easier to control task. A lot of that will of course be what you already typed into the text editor, but it can do quite a lot for you beyond that—such as automatically spreading paragraphs if you’re the sort that doesn’t like to type in double-spaced paragraphs.
If you want to give it a quick try:
- Download and install Pandoc, if necessary. It is a well-respected open source general purpose file conversion utility that specialises in Markdown.
- Restart Scrivener, and open up the compile overview window. If you check the Compile for dropdown at the top, you’ll see a few new Pandoc-specific output options provided—one of which will be ePub.
- Select the “Basic Pandoc” compile Format in the left sidebar. As for Layout assignments, as you can see you’ll be thinking more along the lines of how Markdown files work rather than formatting. Your choices are structural now—this has a heading, that does not, etc.
- Lastly, since your paragraphs aren’t to spec, you will need to make one simple adjustment to the “Basic Pandoc” compile format. This post refers to the LaTeX project template—but all of the built-in Markdown-based compile Formats are set up the way I describe in that post, as well.
With these adjustments made, you should be getting a pretty decent .epub when you compile. In some ways, especially where it comes to the internal HTML quality, I would say it is hands down better than what you’ll get out of Scrivener. What some may consider to be a downside is that it is not styled, and will display using vanilla reader layout. While you were editing the format before, you may have noticed a Pandoc Options tab—in there you can supply the book’s CSS. Feel free to copy some of our CSS from the “Ebook” format, drop in a design you found or make your own.
As for Mobi, if you really need that, drop the .epub onto Kindle Previewer to convert and export as Mobi. There isn’t much of a need for that format these days though, outside of proofing on a device.