I can't believe this isn't already there but...

…judging from this thread, it’s not:

[url]https://forum.literatureandlatte.com/t/latex-epub/24252/2]

It seems to me totally illogical that converting single carriage returns to double ones (i.e. having a blank line between paragraphs) isn’t done as standard when compiling to MMD or Latex via MMD. At the minute, the single carriage returns in my document (which look very nice in rtf or when exported to Word) are left as they are. That means that when I further compile my Latex file to pdf, all the text appears as one enormous paragraph, as Latex (like MMD) uses blank lines to indicate paragraph breaks.

Yes, I know I can (a) write everything in MMD in Scrivener, or (b) do substitutions and transformations and even save them as special options before compiling, but (a) isn’t exactly practical if I’ve imported Word documents into my Scrivener document, and (b) is the type of repetitive reformatting that Scrivener (if I understand correctly) exists to obviate.

Because we cannot presume that this will be safe. There are cases where you use adjacent lines in MMD, such as in code blocks, prose lists, definition lists, tables and meta-data, where inserting empty lines between them would have an adverse syntactic meaning or actually break the syntax altogether. If someone wants to do that, and knows it is safe, then they can do so with Replacements, no big deal.

The best solution, if you must have a hybrid between rich text and plain-text writing styles, is to use visual paragraph spacing for your formatting in the editor, and then set the Convert to plain text drop-down to “Paragraph spacing”. Now those visual spaces will become literal empty lines, exactly where you need them, and never in between things that shouldn’t be spaced out.

I appreciate the answer and the tips. I guess I formulated my request badly. My main gripe is that, if you write in rich text (or import, as in my case, a Microsoft Word document), then compiling straight to MMD does not produce a correct MultiMarkdown document. Specifically paragraphs are not differentiated. (Let’s just confine ourselves here to talking about MMD as other formats such as Latex rely on having correct MultiMarkdown.)

I’m aware that not all rich text formatting can be converted into MMD. I also understand that just inserting a blank line between paragraphs will mess up things such as lists. But if Scrivener is capable of producing other types of markup documents such as HTML from rich text then surely it must be possible to improve the MMD compile function so I don’t have to fiddle about with replacements and the like to fix something so basic as whether a normal text paragraph still looks like a paragraph after compiling? Don’t get me wrong: I am prepared to do some post-processing, just preferably not with the basic formatting.

Maybe I should say here that my principle reasons for using Scrivener isn’t its outlining or organisation functions but its ability to produce several file types from the one source. That’s why I’m labouring this point.

The thing is, Scrivener doesn’t produce or convert anything to a MultiMarkdown document (at least not to the level you’re expecting). This isn’t at all like the HTML converter—more like a plain-text dump of whatever is in the editor. It has integration for MMD, so that one can write using MMD and produce documents without messing with the command-line, and with some of Scrivener’s bespoke features like Preserve Formatting and compiler headings, we produce relevant syntax, but you’re still supposed to be writing a MultiMarkdown document in order to use the MMD features. That may not always be the case, but that’s how it is right now.

In that case we’d need to wait for Apple to make a rich text to MMD converter, because that is what we are using for the HTML export—and if you dig into threads asking for enhancements to HTML, you’ll find we don’t have much control over that. What tweaks we have made to HTML compile are done with what amounts to search and replace (sound familiar?), which can only solve some problems.

Possible to improve, yes: very difficult to improve, emphatically yes. There is a reason why you do not see a flood of RTF to Markdown-ish converters out there, and of those, you will be hard-pressed to find anything that works reliably and does not require extensive page-by-page proofing.

That’s a good reason to use it, and I’d say we tout that just as much as the rest. It’s just not meant to be a principle that extends between word processing style work and semantic document markups. Think of it this way, Scrivener has two principle ways of working: with rich text or with markup. If you choose the markup route you have all of the formats available to Pandoc (not integrated, but possible with the plain MMD export) and MultiMarkdown integration. If you choose the rich text path then you have everything else in the compile menu available to you.

Like I said before, there is the possibility for a hybrid approach, but it’s definitely more limited, doesn’t work for everything (you’ll never get a highlight turned into CriticMarkup, for instance), and you have to prepare for it with rich text formatting settings that work with the whitespace transformation options (not a problem since you can override formatting with the compiler; it just needs to “be hybrid” in the editor itself).

As an MMD user myself, I don’t really find a compelling reason to use a hybrid approach. I certainly could if I wanted to, but I get a better quality word processor file out of MMD (hierarchical stylesheets, real captions, dynamic cross-references, etc.). Scrivener’s e-book output is visually better than what I can get with Pandoc, but the Pandoc result is easier to style by hand with CSS (which is the more appealing option to me). So I don’t really get the appeal of a hybrid approach—but that’s probably mainly because I prefer writing in plain-text to begin with.

OK, that makes sense to me if you just think of it as a plain text dump.

But then, should it really be in the compile menu with all the (if I can put it his way) ‘proper’ conversion options? Because if I understand correctly, the document needs to be in MMD in the first place to be compiled to MMD (and perhaps from MMD onwards into another format).

What I think may confuse people is that if they come to Scrivener, they will probably start writing in it using what you could call a ‘rich text methodology’: one carriage return for a new paragraph; setting italics, bold and underlining using the icons; and so on, much like you would in Word. Doing so will compile nicely to a .doc file or similar. It won’t to MMD. Altering various settings in the compile menu will produce something closer to correct MMD, but it still won’t be perfect. Then - at least this was my experience - the user will conclude he’s not chosen the right settings, when in fact he’s been writing the wrong way from the start.

Possibly I am just setting myself up for a “Try reading the manual first, you idiot”. And in a sense this discussion has turned into a piece of user feedback rather than being a feature request. Thanks for the consideration and advice anyway.

Well, technically, the compiler doesn’t do any format conversion, anywhere. That’s not its purpose. It compiles the 1,532 (or whatever) individual outline sections in your Draft folder into a single document, and there are all of those option panes that do things to the data as it is compiled. Just browse through all of the available option panes with “MultiMarkdown” selected if you think the compiler does nothing for it. :slight_smile:

Now, when Scrivener is all done compiling, it passes that completed document off to the operating system, the built-in Aspose Java document converter or the MultiMarkdown engine—each depending on which format you select and what the best option is for that format. I guess the closest exception to what I’m saying is the ePub/Mobi outputs—Scrivener is much more involved with the construction of then final output file, but even so, many of the internal files are produced using the operating system’s RTF->HTML/CSS converter.

I do not feel there is a whole lot we can do about that potential route of confusion you’ve described (without being obnoxious about it and throwing up warnings when you compile with MMD), but that is why we label the compile options the way we do. One selects something called “MultiMarkdown → Web Page (.html)”. Not “Scrivener Rich Text → MultiMarkdown → Web Page (.html)”.

And yes, the opening two paragraphs of the MultiMarkdown chapter in the user manual do make it clear this is an entirely different way of writing, not an entirely different set of checkboxes. But like you say, who reads manuals. :wink:

Oh, but on going down the wrong path initially and wanting to transition to a different writing method, I’m not sure if I mentioned it before, but there is a conversion tool: Format/Convert/Bold and Italics to MultiMarkdown Syntax, and then with the paragraphs you can do a search and replace in the editor to double them up. The rest you’ll have to manage by hand, mainly because basic rich text (such as Scrivener) has no semantics; there is no block quote, only text that is indented a little differently than other text.