Maybe I shouldn’t write in Markdown, but I do. I am compiling (pandoc=>pub seems to work best) but markdown text is not reliably converting upon compile. I don’t know why.
In Scrivener, third-level (article) headings are set-off as follows:
“### Article One”
“### Article Two”
Most of the time, these compile correctly, but sometimes the Markdown code is treated as text crosshatches. See below. I’d like to know why this happens, and
-what can I do in Scrivener to fix this, or
-how can I fix the compiled epub? Calibre?
Here’s another question that hinted at an answer but the answer wasn’t shared:
That is not valid syntax. You can get away with not having an empty line after the heading line in some Markdown engines, but not before it. I prefer to just keep empty lines between all major blocks to avoid ambiguities and conversion engine differences.
I’m confused by the last screenshot though. You mention using Pandoc → ePub, but seem to be off in some other way of using Scrivener entirely. These settings are not applicable to any Markdown-based outputs.
It looks like you are using Scrivener’s native ePub setting and are thinking that this checkbox is what you need to enable Markdown workflow, but it’s really not. You need to go down further in the Compile for dropdown, all the way to the bottom, and select Pandoc → ePub.
What you are using here is barely worth messing with, it is of dubious utility. As someone using Markdown to write with, just ignore everything in the Compile For menu above the “MultiMarkdown” entry (which, by the way, you should always be using to test whether or not a problem is Scrivener’s or yours—like the above).
I think that writing in the forum editor gobbled the empty lines. I do indeed include empty lines before and after the Markdown code in the Scrivener editor, as shown:
Note that in the example, 279 and 280 are properly formatted in the editor, but on compile, only 279 properly displays and 280 is not set off as a separate article.
The following are compile options–are they not needed?
Note that in the example, 279 and 280 are properly formatted in the editor, but on compile, only 279 properly displays and 280 is not set off as a separate article.
I was referring to the screenshot, not any text in the forum post. You can see only one single newline after “…of the provisions of this Law.”, and the next heading. There is no empty line there. So no, they aren’t properly formatted in the editor, and that’s the problem.
But that said, if you’re typing text into the forum and it doesn’t work right, then that’s a good sign something is wrong. Both the forum and Pandoc/MMD are going to be acting very similar. In other words, you should be able to copy and paste Markdown from Scrivener into the forum and see it work (more advanced and complex compile adjustments aside). If it doesn’t work, then it is probably not valid Markdown and isn’t going to work anywhere.
The following are compile options–are they not needed?
They shouldn’t be relevant, is more the point. Like I said, you need to switch your Compile for setting. These checkboxes don’t even exist if you have the setting correct for Markdown authoring.
Part of the problem was no paragraph (carriage return) before the Markdown code. Others were due to no space between the Markdown command and the first word of the subheading.
But there were still others that failed to display that did not suffer from either of these two deficiencies. I fixed them manually, sometimes just by retyping text or deleting text and repasting it. Strange.
I am not sure how you are seeing those checkboxes then, if that is the Compile for setting you are using. Those settings should only be visible from the “native” Scrivener export methods, and if you consider the wording of them, they wouldn’t make sense for any of the Markdown-based compile file types either. Why would we be converting MultiMarkdown to rich text, when what we’re doing is taking the editor content, saving it to plain text and then passing that to a Markdown conversion engine? Why would we need a special option to convert Markdown in titles and synopses, when that’s going to happen anyway and there would no way for that to not happen short of stripping punctuation marks out of these fields?
Well, at least it sounds like you’re on the right path at this point, even if some of the faults aren’t obvious. I would reiterate my earlier suggestion though, that when you come across something not working right with full automation, stepping back and compiling with the “MultiMarkdown” compile file type so that you can see the .md file that Scrivener will be passing along to Pandoc is the best way to tell if something is wrong. If you copy and paste text from the editor into that file, and it looks different than what compiled, then some setting must be interfering, and in that case I would step back to a very simple stock Format like “Basic Pandoc” to see if it still happens. That would rule out any potential replacements, transformations or other settings that might be deleting newlines unexpectedly. It would give you a sense of where to look.
By and large though, with basic settings, Scrivener should be treating what you type in the editor as the gold standard for what goes into the .md file. It adds stuff on top of that, like images and footnotes, but if you have two newlines it should in theory always print two, and if you have one, it will only print one. It expects you to be following Markdown rules—and consequently should not typically be very mysterious. At least with basic settings. We can make a huge mess of things ourselves with settings.
Both the forum and Pandoc/MMD are going to be acting very similar. In other words, you should be able to copy and paste Markdown from Scrivener into the forum and see it work (more advanced and complex compile adjustments aside). If it doesn’t work, then it is probably not valid Markdown and isn’t going to work anywhere.