You don’t have to do anything special for that when using Pandoc or MultiMarkdown options. These methods assume the source text is Markdown by default, and will be passing it directly through to whichever conversion engine you use.
Pandoc is the method I would use if the source is Markdown and I wanted an ebook. That’s the tl;dr.
You can indeed have Scrivener treat your source as Markdown when using the RTF-based ePub conversion, and it should work fairly well for most things, but it’s not quite as clean a process as sticking with a Markdown workflow, in my experience. It can probably work for simpler source material, straight novels and the such that do not demand many features, but it gets messy when you start using stuff that Scrivener (and the various Mac conversion tools it depends upon) has no clue what to do with.
Footnotes are probably a good example of that, in that how this works is by first internally converting your source to HTML using MultiMarkdown, converting that to RTF, running through oodles of compile code, then converting it to MultiMarkdown, which is then used to convert to HTML, and finally adding more custom HTML on top of that (see what I mean about cleanliness?
). Since HTML doesn’t have native footnotes, and the Mac’s HTML→RTF converter doesn’t handle the casual convention used to portray them, we cannot expect a good result out of manually typed in Markdown footnotes, at least through the rich text method of conversion.
Returning to Pandoc, the inline footnote syntax for it is slightly different:
...base text.^[Here is the footnote content]
Maybe it has a way of working with the other convention as well, but I’m not sure. I’ve attached a simple demonstration project that uses all four of the footnote techniques available to Markdown users. The resulting .epub file looks good to me (save for the fifth test in the middle, that tries to use MultiMarkdown inline footnote syntax).
One last thing, unless you have a reason to use plain-text only in the main editor, Scrivener’s own inline footnote mechanism is going to generally be more flexible and easier to work with—you will note those examples in the sample project work no matter what combination of settings you use. It has better feature support as well, naturally, with tools for searching within them specifically and so forth. It’s maybe something to consider for the next project.
pandoc_footnotes.zip (129 KB)