It is possible to include special metadata at the top of a MultiMarkdown document, such as title, author, etc. This information can then be used to control how MultiMarkdown processes the document, or can be used in certain output formats in special ways. For example:

Title:    A Sample MultiMarkdown Document  
Author:   Fletcher T. Penney  
Date:     February 9, 2011  
Comment:  This is a comment intended to demonstrate  
          metadata that spans multiple lines, yet  
          is treated as a single value.  

The syntax for including metadata is simple.

Metadata “Variables”

You can substitute the value for a metadata key in the body of a document using the following format, where foo and bar are the keys of the desired metadata.

# A Variable in a Heading [%foo] #

A variable in the body [%bar].

“Standard” Metadata keys

There are a few metadata keys that are standardized in MultiMarkdown. You can use any other keys that you desire, but you have to make use of them yourself.

My goal is to keep the list of “standard” metadata keys as short as possible.


This value represents the author of the document and is used in LaTeX, ODF, and RTF documents to generate the title information.


This is used to enter further information about the author — a link to a website, the name of an employer, academic affiliation, etc.

Base Header Level

This is used to change the top level of organization of the document. For example:

Base Header Level: 2

# Introduction #

Normally, the Introduction would be output as <h1> in HTML, or \part{} in LaTeX. If you’re writing a shorter document, you may wish for the largest division in the document to be <h2> or \chapter{}. The Base Header Level metadata tells MultiMarkdown to change the largest division level to the specified value.

This can also be useful when combining multiple documents.

Base Header Level does not trigger a complete document.

Additionally, there are “flavors” of this metadata key for various output formats so that you can specify a different header level for different output formats — e.g. LaTeX Header Level, HTML Header Level, and ODF Header Level.

If you are doing something interesting with File Transclusion, you can also use a negative number here. Since metadata is not used when a file is “transcluded”, this allows you to use a different level of headings when a file is processed on its own.

Biblio Style

This metadata specifies the name of the BibTeX style to be used, if you are not using natbib.


This metadata specifies the name of the BibTeX file used to store citation information. Do not include the trailing ‘.bib’.

This can be used to provide a copyright string.


This metadata specifies a URL to be used as a CSS file for the produced document. Obviously, this is only useful when outputting to HTML.


Specify a date to be associated with the document.

HTML Header

You can include raw HTML information to be included in the header. MultiMarkdown doesn’t perform any validation on this data — it just copies it as is.

As an example, this can be useful to link your document to a working MathJax installation (not provided by me):

HTML header:  <script type="text/javascript"

Quotes Language

This is used to specify which style of “smart” quotes to use in the output document. The available options are:

The default is english if not specified. This affects HTML output. To change the language of a document in LaTeX is up to the individual.

Quotes Language does not trigger a complete document.

LaTeX Author

Since MultiMarkdown syntax is not processed inside of metadata, you can use the latex author metadata to override the regular author metadata when exporting to LaTeX.

This metadata must come after the regular author metadata if it is also being used.

LaTeX Footer

A special case of the LaTeX Input metadata below. This file will be linked to at the very end of the document.

LaTeX Input

When outputting a LaTeX document it is necessary to include various directions that specify how the document should be formatted. These are not included in the MultiMarkdown document itself — instead they should be stored separately and linked to with \input{file} commands.

These links can be included in the metadata section. The metadata is processed in order, so I generally break my directives into a group that need to go before my metadata, a group that goes after the metadata but before the document itself, and a separate group that goes at the end of the document, for example:

latex input:        mmd-memoir-header
Title:              MultiMarkdown Example
Base Header Level:  2
latex mode:         memoir
latex input:        mmd-memoir-begin-doc
latex footer:       mmd-memoir-footer

You can download the LaTeX Support Files if you want to output documents using the default MultiMarkdown styles. You can then use these as examples to create your own customized LaTeX output.

This function should allow you to do almost anything you could do using the XSLT features from MultiMarkdown 2.0. More importantly, it means that advanced LaTeX users do not have to learn XSLT to customize their code as desired.

LaTeX Mode

When outputting a document to LaTeX, there are two special options that change the output slightly — memoir and beamer. These options are designed to be compatible with the LaTeX classes of the same names.

LaTeX Title

Since MultiMarkdown syntax is not processed inside of metadata, you can use the latex title metadata to override the regular title metadata when exporting to LaTeX.

This metadata must come after the regular title metadata if it is also being used.

MMD Footer

The MMD Footer metadata is used to specify the name of a file that should be appended to the end of the document using the File Transclusion feature. This is useful for keeping a list of references, abbreviations, footnotes, links, etc. all in a single file that can be reused across multiple documents. If you’re building a big document out of smaller documents, this allows you to use one list in all files, without multiple copies being inserted in the master file.

ODF Header

You can include raw XML to be included in the header of a file output in OpenDocument format. It’s up to you to properly format your XML and get it working — MultiMarkdown just copies it verbatim to the output.



Transclude Base

When using the File Transclusion feature to “link” to other documents inside a MultiMarkdown document, this metadata specifies a folder that contains the files being linked to. If omitted, the default is the folder containing the file in question. This can be a relative path or a complete path.

This metadata can be particularly useful when using MultiMarkdown to parse a text string that does not exist as a file on the computer, and therefore does not have a parent folder (when using stdin or another application that offers MultiMarkdown support). In this case, the path must be a complete path.

Smart Typography

MultiMarkdown incorporates John Gruber’s SmartyPants tool in addition to the core Markdown functionality. This program converts “plain” punctuation into “smarter” typographic punctuation.

Just like the original, MultiMarkdown converts:

MultiMarkdown also includes support for quotes styles other than English (the default). Use the quotes language metadata to choose:

This feature is enabled by default, but is disabled in compatibility mode, since it is not part of the original Markdown. You can also use the smart and nosmart command line options to control this feature.


An oft-requested feature was the ability to have Markdown automatically handle within-document links as easily as it handled external links. To this aim, I added the ability to interpret [Some Text][] as a cross-link, if a header named “Some Text” exists.

As an example, [Metadata][] will take you to the section describing metadata.

Alternatively, you can include an optional label of your choosing to help disambiguate cases where multiple headers have the same title:

### Overview [MultiMarkdownOverview] ##

This allows you to use [MultiMarkdownOverview] to refer to this section specifically, and not another section named Overview. This works with atx- or settext-style headers.

If you have already defined an anchor using the same id that is used by a header, then the defined anchor takes precedence.

In addition to headers within the document, you can provide labels for images and tables which can then be used for cross-references as well.

Link and Image Attributes

Adding attributes to links and images has been requested for a long time on the Markdown discussion list. I was fairly opposed to this, as most of the proposals really disrupted the readability of the syntax. I consider myself a “Markdown purist”, meaning that I took John’s introduction to heart:

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

Because there was not a syntax proposal that I felt fit this goal, I was generally opposed to the idea.

Then, Choan C. Gálvez proposed a brilliantly simple syntax that stayed out of the way. By simply appending the attributes to the link reference information, which is already removed from the text itself, it doesn’t disturb the readability.

For example:

This is a formatted ![image][] and a [link][] with attributes.

[image]: "Image title" width=40px height=400px
[link]: "Some Link" class=external
         style="border: solid black 1px;"

This will generate width and height attributes for the image, and a border around the link. And while it can be argued that it does look “like it’s been marked up with tags [and] formatting instructions”, even I can’t argue too strongly against it. The link and the title in quotes already look like some form of markup, and the the additional tags are hardly that intrusive, and they offer a great deal of functionality. They might even be useful in further functions (citations?).

The attributes must continue after the other link/image data, and may contain newlines, but must start at the beginning of the line. The format is attribute=value or attribute="multi word value". Currently, MultiMarkdown does not attempt to interpret or make any use of any of these attributes. Also, you can’t have a multiword attribute span a newline.


The basic syntax for images in Markdown is:

![Alt text](/path/to/img.jpg)

![Alt text](/path/to/img.jpg "Optional title")

![Alt text][id]

[id]: url/to/image  "Optional title attribute"

In addition to the attributes you can use with links and images (described in the previous section), MultiMarkdown also adds a few additional things. If an image is the only thing in a paragraph, it is treated as a block level element:

This image (![Alt text](/path/to/img.jpg))
is different than the following image:

![Alt text](/path/to/img.jpg)

The resulting HTML is:

<p>This image (<img src="/path/to/img.jpg" alt="Alt text" />)
is different than the following image:</p>

<img src="/path/to/img.jpg" alt="Alt text" />
<figcaption>Alt text</figcaption>

The first one would be an inline image. The second one (in HTML) would be wrapped in an HTML figure element. In this case, the alt text is also used as a figure caption, and can contain MultiMarkdown syntax (e.g. bold, emph, etc.). The alt text is not specifically designed to limit which MultiMarkdown is supported, but there will be limits and block level elements aren’t supported.


Table Basics

MultiMarkdown has a special syntax for creating tables. It is generally compatible with the syntax used by Michael Fortin for PHP Markdown Extra

Basically, it allows you to turn:

|             |          Grouping           ||
First Header  | Second Header | Third Header |
 ------------ | :-----------: | -----------: |
Content       |          *Long Cell*        ||
Content       |   **Cell**    |         Cell |

New section   |     More      |         Data |
And more      | With an escaped '\|'         ||  
[Prototype table]

into the following table.

Prototype table
First Header Second Header Third Header
Content Long Cell
Content Cell Cell
New section More Data
And more With an escaped ‘|’

Table Rules

The requirements are:

Other notes:

Limitations of Tables


I have added support for footnotes to MultiMarkdown, using the syntax proposed by John Gruber. Note that there is no official support for footnotes yet, so the output format may change, but the input format sounds fairly stable.

To create a footnote, enter something like the following:

Here is some text containing a footnote.[^somesamplefootnote]

[^somesamplefootnote]: Here is the text of the footnote itself.


The footnote itself must be at the start of a line, just like links by reference. If you want a footnote to have multiple paragraphs, lists, etc., then the subsequent paragraphs need an extra tab preceding them. You may have to experiment to get this just right, and please let me know of any issues you find.

This is what the final result looks like:

Here is some text containing a footnote.[1]

You can also use “inline footnotes”:

Here is another footnote.[^This is the footnote itself]


I have included support for basic bibliography features in this version of MultiMarkdown. Please give me feedback on ways to improve this but keep the following in mind:

  1. Bibliography support in MultiMarkdown is rudimentary. The goal is to offer a basic standalone feature, that can be changed using the tool of your choice to a more robust format (e.g. BibTeX, CiteProc). My XSLT files demonstrate how to make this format compatible with BibTeX, but I am not planning on personally providing compatibility with other tools. Feel free to post your ideas and tools to the wiki.

  2. Those needing more detailed function sets for their bibliographies may need customized tools to provide those services. This is a basic tool that should work for most people. Reference librarians will probably not be satisfied however.

To use citations in MultiMarkdown, you use a syntax much like that for anchors:

This is a statement that should be attributed to
its source[p. 23][#Doe:2006].

And following is the description of the reference to be
used in the bibliography.

[#Doe:2006]: John Doe. *Some Big Fancy Book*.  Vanity Press, 2006.

In HTML output, citations are indistinguishable from footnotes.

You are not required to use a locator (e.g. p. 23), and there are no special rules on what can be used as a locator if you choose to use one. If you prefer to omit the locator, just use an empty set of square brackets before the citation:

This is a statement that should be attributed to its 

There are no rules on the citation key format that you use (e.g. Doe:2006), but it must be preceded by a #, just like footnotes use ^.

As for the reference description, you can use Markup code within this section, and I recommend leaving a blank line afterwards to prevent concatenation of several references. Note that there is no way to reformat these references in different bibliography styles; for this you need a program designed for that purpose (e.g. BibTeX).

If you want to include a source in your bibliography that was not cited, you may use the following:

[Not cited][#citekey]

The Not cited bit is not case sensitive.

If you are creating a LaTeX document, the citations will be included, and natbib will be used by default. If you are not using BibTeX and are getting errors about your citations not being compatible with ‘Author-Year’, you can add the following to your documents metadata:

latex input:        mmd-natbib-plain

This changes the citation style in natbib to avoid these errors, and is useful when you include your citations in the MultiMarkdown document itself.


If you are creating a LaTeX document, and need a bibliography, then you should definitely look into BibTeX and natbib. It is beyond the scope of this document to describe how these two packages work, but it is possible to combine them with MultiMarkdown.

To use BibTeX in a MultiMarkdown document, you need to use the BibTeX metadata to specify where your citations are stored.

Since natbib is enabled by default, you have a choice between using the \citep and \citet commands. The following shows how this relates to the MultiMarkdown syntax used.

[#citekey]    => ~\citep{citekey}
[#citekey][]  => ~\citep{citekey}

[foo][#citekey] => ~\citep[foo]{citekey}

[foo\]\[bar][#citekey] => ~\citep[foo][bar]{citekey}

[#citekey;]    => \citet{citekey}
[#citekey;][]  => \citet{citekey}

[foo][#citekey;] => \citet[foo]{citekey}

[foo\]\[bar][#citekey;] => \citet[foo][bar]{citekey}

Definition Lists

MultiMarkdown has support for definition lists using the same syntax used in PHP Markdown Extra. Specifically:

:   Pomaceous fruit of plants of the genus Malus in 
    the family Rosaceae.
:   An american computer company.

:   The fruit of an evergreen tree of the genus Citrus.


Pomaceous fruit of plants of the genus Malus in the family Rosaceae.
An american computer company.
The fruit of an evergreen tree of the genus Citrus.

You can have more than one term per definition by placing each term on a separate line. Each definition starts with a colon, and you can have more than one definition per term. You may optionally have a blank line between the last term and the first definition.

Definitions may contain other block level elements, such as lists, blockquotes, or other definition lists.

Unlike PHP Markdown Extra, all definitions are wrapped in <p> tags. First, I was unable to get Markdown not to create paragraphs. Second, I didn’t see where it mattered - the only difference seems to be aesthetic, and I actually prefer the <p> tags in place. Let me know if this is a problem.

See the PHP Markdown Extra page for more information.


MultiMarkdown includes support for abbreviations, as implemented in Michel Fortin’s PHP Markdown Extra. Basically, you define an abbreviation using the following syntax:

*[HTML]: HyperText Markup Language
*[W3C]:  World Wide Web Consortium

Then, wherever you use the words HTML or W3C in your document, the abbr markup will be added:

The HTML specification
is maintained by the W3C.


The <abbr title="Hyper Text Markup Language">HTML</abbr> specification
is maintained by the <abbr title="World Wide Web Consortium">W3C</abbr>.

Here’s an example using HTML and W3C. The exact behavior will depend on which format you are viewing this document in. Especially if we use HTML and W3C again. (Remember that HTML has probably already been used if you’re viewing a longer version of this document.)

As in PHP Markdown Extra, abbreviations are case-sensitive and will work on multiple word abbreviations. In this case, MultiMarkdown is tolerant of different variations of whitespace between words.

Operation Tigra Genesis is going well.

*[Tigra Genesis]:

An abbreviation with an empty definition results in an omitted title attribute.

There are a few limitations:

Fenced Code Blocks

In addition to the regular indented code block that Markdown uses, you can use “fenced” code blocks in MultiMarkdown. These code blocks do not have to be indented, and can also be configured to be compatible with a third party syntax highlighter. These code blocks should begin with 3 to 5 backticks, an optional language specifier (if using a syntax highlighter), and should end with the same number of backticks you started with:

# Demonstrate Syntax Highlighting if you link to highlight.js #
print "Hello, world!\n";
$a = 0;
while ($a < 10) {
print "$a...\n";

I don’t recommend any specific syntax highlighter, but have used the following metadata to set things up. It may or may not work for you:

html header:    <link rel="stylesheet" href="">
    <script src=""></script>

Fenced code blocks are particularly useful when including another file (File Transclusion), and you want to show the source of the file, not what the file looks like when processed by MultiMarkdown.


MultiMarkdown 2.0 used ASCIIMathML to typeset mathematical equations. There were benefits to using ASCIIMathML, but also some disadvantages.

When rewriting for MultiMarkdown 3.0, there was no straightforward way to implement ASCIIMathML which lead me to look for alternatives. I settled on using MathJax. The advantage here is that the same syntax is supported by MathJax in browsers, and in LaTeX.

This does mean that math will need to be entered into MultiMarkdown documents using the LaTeX syntax, rather than ASCIIMathML.

To enable MathJax support in web pages, you have to include a link to an active MathJax installation — setting this up is beyond the scope of this document, but it’s not too hard.

Here’s an example of the metadata setup, and some math:

latex input:    mmd-article-header  
Title:          MultiMarkdown Math Example  
latex input:    mmd-article-begin-doc  
latex footer:   mmd-memoir-footer  
HTML header:    <script type="text/javascript"

An example of math within a paragraph --- \\({e}^{i\pi }+1=0\\)
--- easy enough.

And an equation on it's own:

\\[ {x}_{1,2}=\frac{-b\pm \sqrt{{b}^{2}-4ac}}{2a} \\]

That's it.

Here’s what it looks like in action (if you’re viewing this document in a supported format):

An example of math within a paragraph — \({e}^{i\pi }+1=0\) — easy enough.

And an equation on it’s own:

\[ {x}_{1,2}=\frac{-b\pm \sqrt{{b}^{2}-4ac}}{2a} \]

That’s it.

In addition to the \\[ \\] and \\( \\) syntax, you can use LaTeX style “dollar sign” delimiters:

An example of math within a paragraph --- ${e}^{i\pi }+1=0$
--- easy enough.

And an equation on it's own:

$${x}_{1,2}=\frac{-b\pm \sqrt{{b}^{2}-4ac}}{2a}$$

That's it.

In order to be correctly parsed as math, there must not be any space between the $ and the actual math on the inside of the delimiter, and there must be space on the outside.

Superscripts and Subscripts

You can easily include superscripts and subscripts in MultiMarkdown as well:

This apartment has an area of 100m^2
One must consider the value of x~z


This apartment has an area of 100m2
One must consider the value of xz

The subscript must not contain any whitespace or punctuation.

More complicated exponents and subscripts can be delimited like this:




MultiMarkdown has a feature that allows footnotes to be specified as glossary terms. It doesn’t do much for XHTML documents, but the XSLT file that converts the document into LaTeX is designed to convert these special footnotes into glossary entries.

The glossary format for the footnotes is:

[^glossaryfootnote]: glossary: term (optional sort key)
    The actual definition belongs on a new line, and can continue on
    just as other footnotes.

The term is the item that belongs in the glossary. The sort key is optional, and is used to specify that the term should appear somewhere else in the glossary (which is sorted in alphabetical order).

Unfortunately, it takes an extra step to generate the glossary when creating a pdf from a latex file:

  1. You need to have the basic.gst file installed, which comes with the memoir class.

  2. You need to run a special makeindex command to generate the .glo file: makeindex -s `kpsewhich basic.gst` -o "filename.gls" "filename.glo"

  3. Then you run the usual pdflatex command again a few times.

Alternatively, you can use the code below to create an engine file for TeXShop (it belongs in ~/Library/TeXShop/Engines). You can name it something like MemoirGlossary.engine. Then, when processing a file that needs a glossary, you typeset your document once with this engine, and then continue to process it normally with the usual LaTeX engine. Your glossary should be compiled appropriately. If you use TeXShop, this is the way to go.

Note: Getting glossaries to work is a slightly more advanced LaTeX feature, and might take some trial and error the first few times.


set path = ($path /usr/local/teTeX/bin/powerpc-apple-darwin-current 
    /usr/local/bin) # This is actually a continuation of the line above

set basefile = `basename "$1" .tex`

makeindex -s `kpsewhich basic.gst` -o "${basefile}.gls" "${basefile}.glo"


What Is CriticMarkup?

CriticMarkup is a way for authors and editors to track changes to documents in plain text. As with Markdown, small groups of distinctive characters allow you to highlight insertions, deletions, substitutions and comments, all without the overhead of heavy, proprietary office suites.

CriticMarkup is integrated with MultiMarkdown itself, as well as MultiMarkdown Composer. I encourage you to check out the web site to learn more as it can be a very useful tool. There is also a great video showing CriticMarkup in use while editing a document in MultiMarkdown Composer.

The CriticMarkup Syntax

The CriticMarkup syntax is fairly straightforward. The key thing to remember is that CriticMarkup is processed before any other MultiMarkdown is handled. It’s almost like a separate layer on top of the MultiMarkdown syntax.

When editing in MultiMarkdown Composer, you can have CriticMarkup syntax flagged in the both the editor pane and the preview window. This will allow you to see changes in the HTML preview.

When using CriticMarkup with MultiMarkdown itself, you have four choices:

CriticMarkup comments and highlighting are ignored when processing.

Deletions from the original text:

This is {--is --}a test.


This {++is ++}a test.


This {~~isn't~>is~~} a test.


This is a {==test==}.


This is a test{>>What is it a test of?<<}.

My philosophy on CriticMarkup

I view CriticMarkup as two things:

  1. A syntax for documenting editing notes and changes, and for collaborating amongst coauthors.

  2. A means to display those notes/changes in the HTML output.

I believe that #1 is a really great idea, and well implemented. #2 is not so well implemented, largely due to the “orthogonal” nature of CriticMarkup and the underlying Markdown syntax.

CM is designed as a separate layer on top of Markdown/MultiMarkdown. This means that a Markdown span could, for example, start in the middle of a CriticMarkup structure, but end outside of it. This means that an algorithm to properly convert a CM/Markdown document to HTML would be quite complex, with a huge number of edge cases to consider. I’ve tried a few (fairly creative, in my opinion) approaches, but they didn’t work. Perhaps someone else will come up with a better solution, or will be so interested that they put the work in to create the complex algorithm. I have no current plans to do so.

Additionally, there is a philosophical distinction between documenting editing notes, and using those notes to produce a “finished” document (e.g. HTML or PDF) that keeps those editing notes intact (e.g. strikethroughs, highlighting, etc.) I believe that CM is incredibly useful for the editing process, but am less convinced for the output process (I know many others disagree with me, and that’s ok. And to be clear, I think that what Gabe and Erik have done with CriticMarkup is fantastic!)

There are other CriticMarkup tools besides MultiMarkdown and MultiMarkdown Composer, and you are more than welcome to use them.

For now, the official MultiMarkdown support for CriticMarkup consists of:

  1. CriticMarkup syntax is “understood” by the MultiMarkdown parser, and by MultiMarkdown Composer syntax highlighting.
  2. When converting from MultiMarkdown text to an output format, you can ignore CM formatting (probably not what you want to do), accept all changes, or reject all changes (as above). These are the preferred choices.
  3. The secondary to choice, when exporting to HTML, is to attempt to show the changes in the HTML output. Because the syntaxes are orthogonal, this will not always work properly, and will not always give valid HTML output.


You can include raw (X)HTML within your document. Exactly what happens with these portions depends on the output format. You can also use the markdown attribute to indicate that MultiMarkdown processing should be applied within the block level HTML tag. This is in addition to the --process-html command line option that causes MultiMarkdown processing to occur within all block level HTML tags.

For example:

<div>This is *not* MultiMarkdown</div>

<div markdown=1>This *is* MultiMarkdown</div>

will produce the following without --process-html:

<div>This is *not* MultiMarkdown</div>

<div>This <em>is</em> MultiMarkdown</div>

and with --process-html:

<div>This is <em>not</em> MultiMarkdown</div>

<div>This <em>is</em> MultiMarkdown</div>

However, the results may be different than anticipated when outputting to LaTeX or other formats. Normally, block level HTML will be ignored when outputting to LaTeX or ODF. The example above would produce the following, leaving out the first <div> entirely:

This \emph{is} MultiMarkdown

And this with --process-html:

This is \emph{not} MultiMarkdown
This \emph{is} MultiMarkdown

You will also notice that the line breaks are different when outputting to LaTeX or ODF, and this can cause the contents of two <div> tags to be placed into a single paragraph.

Raw LaTeX/OpenDocument/etc.

You can use HTML comments to include additional text that will be included in the exported file without being changed. This can be used for any export format, which means that each document can only be configured for one export format at a time. In other words, it is highly unlikely that valid raw LaTeX will also be valid OpenDocument source code.

This will be processed by *MultiMarkdown*.
<!-- This will not be processed by *MultiMarkdown -->

File Transclusion

File transclusion is the ability to tell MultiMarkdown to insert the contents of another file inside the current file being processed. For example:

This is some text.


Another paragraph

If a file named some_other_file.txt exists, its contents will be inserted inside of this document before being processed by MultiMarkdown. This means that the contents of the file can also contain MultiMarkdown formatted text.

If you want to display the contents of the file without processing it, you can include it in a code block (you may need to remove trailing newlines at the end of the document to be included):

This is some text


Another paragraph

Transclusion is recursive, so the file being inserted will be scanned to see if it references any other files.

Metadata in the file being inserted will be ignored. This means that the file can contain certain metadata when viewed alone that will not be included when the file is transcluded by another file.

You can use the [Transclude Base] metadata to specify where MultiMarkdown should look for the files to be included. All files must be in this folder. If this folder is not specified, then MultiMarkdown will look in the same folder as the parent file.

Note: Thanks to David Richards for his ideas in developing support for this feature.

Wildcard Extensions

Sometimes you may wish to transclude alternate versions of a file depending on your output format. Simply use the extension “.*” to have MMD choose the proper version of the file (e.g. foo.tex, foo.fodt, foo.html, etc.)

Insert a different version of a file here based on export format:

Transclusion Preprocessing

If you want to perform transclusion, without converting to another format, you can use mmd as the output format:

multimarkdown -t mmd foo.txt

This will only perform “basic” transclusion –it does not support wildcard extensions, since the final output format is not known.

Escaped newlines

Thanks to a contribution from Nicolas, MultiMarkdown has an additional syntax to indicate a line break. The usual approach for Markdown is “space-space-newline” — two spaces at the end of the line. For some users, this causes problems:

Nicolas submitted a patch that enables a new option that interprets “\” before a newline as a marker that a line break should be used:

This is a line.\
This is a new line.

To enable this feature, use the following option:

multimarkdown --escaped-line-breaks file.txt

If this option is not enabled, then the default behavior will be to treat the newline as an escaped character, which results in it simply appearing as a newline character in the output. This means that the default behavior is the same as if the “\” is not in the source file.

  1. Here is the text of the footnote itself.  ↩