Just finished my NaNoWriMo project. I am using the template “Novel with parts” and when I compile the Manuscript folder, it does correctly create all the chapters for the folders I set up.
But my text is one huge chunk in the compiled file. Basically, every time I hit Return on my keyboard to start a new paragraph – that’s all gone in the mobi file (and in epub as well). I checked it on the Kindle Previewer app and it looks like there, too. It’s kinda hard to read dialog when everything is just mashed together.
I thought that I might have messed up formatting (I’m not familiar at all with how any of that works … use Markdown for writing everything and have actually hidden the formatting bar in Scrivener because it’s confusing me) so I created a new Scrivener project and used “Copy and Match Style” to copy the text from one scene into a fresh scene card in the new project. Same problem.
I googled for “Scrivener compile paragraphs lost” and similar stuff, but nothing came up that matches this problem.
I wrote about half of the novel in a markdown app and just copied the text over into Scrivener because it’s easier to manage there, and the other half of the novel I wrote directly in Scrivener. There is no difference – the problem exists in every scene file.
macOS 12.0.1
Scrivener v3.3.3
I’ve already exported everything to Markdown because that’s where I do all my editing, but I’d rather compile via Scrivener because it removes a lot of manual work. Would be really grateful for any tips.
Are you using double carriage returns to indicate a new para?
If no, not the best approach, especially if you have compile option set to remove them. I’m on iPad at present do can’t dive down yo the sequence for you.
For new para a single return with new para formatted for space before works for me.
Apologies in advance if that sounds a bit gobbledygook on nasty painkillers that come with warning on impaired logic/decision making. Hopefully only a few more dsys.
Nope, only hitting Return once to start a new paragraph. I tried to attach a screenshot, but it doesn’t let me do that. Basically, if I select text, I can see the inverted P thingy at the end of each line (meaning I hit the Return key there). I assumed that this was enough to create a new paragraph. Again, not familiar at all with this Rich Text stuff, I never use it anywhere
In the Multimarkdown export, everything works, though. Everything that should be a new paragraph is a new paragraph there. It only seems to fail in the epub and mobi export.
Are those paragraphs separated by a blank line in Markdown? If not (as I suspect) the HTML-export – that’s the foundation for those ebook formats – fails correctly. At best you’ll get some hard line breaks (br), but it’ll be more or less a big dump of text.
Yeah, they are not separated by empty lines in MD.
But how do I fix this in Scrivener? Is there a button I can press to get this fixed? I have 99K words (yeah, I know, I’m in the process of editing) so manually inserting line breaks isn’t really an option.
Since export to eBook is an option in Scrivener, there must be a feature for this to work correctly, right?
It depends. I can think of a lot of options, but there’s no single “I fucked it up, fix it for me”-button (that I know of). On a very basic level a simple search/replace of single line breaks → double line breaks should do it.
But I’m wondering… since your Markdown software seems to handle these “fake paragraphs” well, doesn’t it offer some sort of export / conversion to “proper” Markdown?
I haven’t looked into that yet, tbh. I thought if I had my text in an app that is made for compiling to ebooks I wouldn’t have to worry about formatting. I guess I’ll only use Scrivener for outlining then, and go back to Markdown apps for everything else. That’s too bad. I liked that compiling was so easy.
Why does it have to be a “this or that” decision (for now, and most importantly: thinking forward)? We didn’t even start to fix your issue. I agree that you shouldn’t have to worry about formatting too much while writing. Or at all. But structuring is a different story.
Alright, asked my developers (not for Scrivener; we develop our own apps) because they know more about technical stuff than I do. Here’s how I fixed this:
Put the cursor at the end of a line.
Hold down SHIFT and hit the right-arrow key. This’ll select the inverted P character (which is the /newline character, as I’ve learned).
Cmd+C to copy this.
Edit → Find → Search in Project.
In the search field, hit Cmd+V once to paste in the inverted P character.
In the replace field, hit Cmd+V TWICE.
And voila. Now I have real paragraphs. Export to Kindle format gives me the perfect formatting. Seems that if I write again in Scrivener, I have to hit Return TWICE in order to avoid all of this.
Is there a setting somewhere that will do this for me automatically?
I don’t think so (but what do I know). You could try the paragraph handling settings of the Sync with External Folder mechanism. If you use that. To be honest: I just hit Enter twice in anything Plain Text.
@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.
I agree that you shouldn’t have to worry about formatting too much while writing. Or at all. But structuring is a different story.