I understand the difficulties, but I don’t understand why they haven’t been able to teach these rich text editors that extra line breaks are accomplished with the <p> tag. Oh well.
Well they do, as you noted above, but some readers will not show an empty element as being anything, so if you just have an empty p element by itself, it won’t serve as a spacer. Putting something in it resolves that. I wouldn’t myself put a br, but there is probably no “right” way of doing that, since it’s kind of the wrong approach to begin with. If something needs extra space, it should be done so with formatting, not with content work-arounds, like extra paragraph breaks. A paragraph with an extended margin or padding on the bottom edge is what really should be used. But a word processor isn’t going to do that by itself.
something you can influence with the paragraph spacing tools in Scrivener. Maybe consider spacing instead of a literal empty line, where you need them. I wouldn’t overly worry about this though, unless you want to adjust the amount of spacing and find that difficult with a full carriage return in there.
I’d found the Convert to Markdown feature earlier, so I knew about that trick. Would compiling to Multimarkdown do all of that automatically? I’ll probably figure this out on my own in just a second when I give it a try.
Not at this time, it’s a fully manual process and only handles bold and italic. There are a few things Scrivener can generate MultiMarkdown code for. Check the user manual’s chapter on MMD for details on what can be compiled.
But that is why I wondered if switching to a different form or writing at this point may be too much work. I suppose if the book is relatively “simple” in regards to formatting, it wouldn’t be too much.
I have folders for each chapter with docs under each, and for some reason pandoc has not separated out each document.
Do these document levels have headings in your Formatting pane settings? You’ll need that, so that you can get h2 or h3 or whatever headings, and then you will need to instruct Pandoc to use that depth for where file breaks should occur internally in the ePub, with --epub-chapter-level=#
, where the number is the h# depth.
That is a technical detail however—you shouldn’t need to cut things up into tiny files inside the ePub, this setting is more for optimising against very long HTML files, which can bog down some readers. If you’re mainly just interested in manipulating the ToC, then all you need to know is that headings are used to create the ToC (even coming from the same technical HTML file, that doesn’t really matter, save for the performance concerns mentioned).
(And of course, one has full control of the ToC in Sigil/Calibre after compiling, so this is mainly about getting the majority of the grunt work done if you can’t find a setting that works perfectly.)
The simplest way to go, though, is to accept what Scrivener and the OSX tools give you. The code may not be as clean as you would like but so long as the output looks OK, your readers will not be irked. And you will have saved yourself some time and headaches.
I do second that, unless you are an HTML/CSS jockey and you’re looking for a clean start to do semantic styling against (and not having to wrestle with sequentially assigned class names).
Here’s the thing: you’ll get a consistent look with what Scrivener generates natively, because it’s using the same exact HTML/CSS tools a guru would be using. It might be a little messier and more verbose than a hand-coded CSS file (let alone that the engine creates a new CSS document for every HTML file even if the style is the same in every single one), but it works
, and it works on the same principle as a hand-crafted ePub. So that’s my advice—unless you want to get in there and design the book personally, don’t worry too much about Scrivener’s output not being good for e-books. We do take care to make sure the output looks good in a broad range of readers.