Directives begin with an explicit markup start (two periods and a
space), followed by the directive type and two colons (collectively,
the "directive marker"). The directive block begins immediately after
the directive marker, and includes all subsequent indented lines. The
directive block is divided into arguments, options (a field list), and
content (in that order), any of which may appear. See the Directives
section in the reStructuredText Markup Specification for syntax
details.
Descriptions below list "doctree elements" (document tree element
names; XML DTD generic identifiers) corresponding to individual
directives. For details on the hierarchy of elements, please see The
Docutils Document Tree and the Docutils Generic DTD XML document
type definition. For directive implementation details, see Creating
reStructuredText Directives.
Admonitions ("safety messages" or "hazard statements") can appear anywhere
an ordinary body element can. They contain arbitrary body elements.
Typically, an admonition is rendered as an offset block in a document,
sometimes outlined or shaded.
Any text immediately following the directive indicator (on the same
line and/or indented on following lines) is interpreted as a directive
block and is parsed for normal body elements. For example, the
following "note" admonition directive contains one paragraph and a
bullet list consisting of two list items:
.. note:: This is a note admonition.
This is the second line of the first paragraph.
- The note contains all indented body elements
following.
- It includes this bullet list.
This is a generic, titled admonition. The title may be anything the
author desires.
The author-supplied title is also used as a classes attribute value
after identifier normalization and adding the prefix "admonition-".
For example, this admonition:
.. admonition:: And, by the way...
You can make up your own admonition too.
becomes the following document tree (pseudo-XML):
<document source="test data">
<admonition classes="admonition-and-by-the-way">
<title>
And, by the way...
<paragraph>
You can make up your own admonition too.
A URI reference to the image source file is specified in the directive
argument. As with hyperlink targets, the image URI may begin on the
same line as the explicit markup start and target name, or it may
begin in an indented text block immediately following, with no
intervening blank lines. If there are multiple lines in the link
block, they are stripped of leading and trailing whitespace and joined
together.
Optionally, the image link block may contain a flat field list, the
image options. For example:
.. image:: picture.jpeg
:height: 100px
:width: 200 px
:scale: 50 %
:loading: embed
:alt: alternate text
:align: right
|Red light| means stop, |green light| means go.
.. |red light| image:: red_light.png
:align: top
.. |green light| image:: green_light.png
:align: bottom
The "image" directive recognizes the common options class
and name as well as
align"top", "middle", "bottom", "left", "center", or "right"
The alignment of the image, equivalent to the HTML <img> tag's
deprecated "align" attribute or the corresponding "vertical-align" and
"text-align" CSS properties.
The values "top", "middle", and "bottom"
control an image's vertical alignment (relative to the text
baseline); they are only useful for inline images (substitutions).
The values "left", "center", and "right" control an image's
horizontal alignment, allowing the image to float and have the
text flow around it. The specific behaviour depends upon the
browser or rendering software used.
Alternate text: a short description of the image, displayed by
applications that cannot display images, or spoken by applications
for visually impaired users.
The desired height of the image.
Used to reserve space or scale the image vertically. When the scale
option is also specified, they are combined. For example, a height of
200px and a scale of 50 is equivalent to a height of 100px with no scale.
loading"embed", "link", or "lazy"
Set the loading attribute to indicate the
preferred handling by the Docutils Writer. [5]
Refer to the image. The HTML5 writer additionally
specifies the "lazy loading attribute".
(New in Docutils 0.21.)
scaleinteger percentage (the "%" symbol is optional)
The uniform scaling factor of the image. The default is "100 %",
i.e. no scaling.
If the output format does not support a scaling attribute (e.g. HTML),
the Docutils writer tries to determine missing size specifications from
the image file (requires the Python Imaging Library).
Nest the image in a hyperlink reference element (make it "clickable").
The option argument may be a URI reference or a reference name
with underscore suffix (e.g. `a name`_).
The width of the image.
Used to reserve space or scale the image horizontally. As with height
above, when the scale option is also specified, they are combined.
Interpreted as the figure caption and an optional
legend.
A "figure" consists of image data (including image options), an optional
caption (a single paragraph), and an optional legend (arbitrary body
elements). For page-based output media, figures might float to a different
position if this helps the page layout.
.. figure:: picture.png
:scale: 50 %
:alt: map to buried treasure
This is the caption of the figure (a simple paragraph).
The legend consists of all elements after the caption. In this
case, the legend consists of this paragraph and the following
table:
+-----------------------+-----------------------+
| Symbol | Meaning |
+=======================+=======================+
| .. image:: tent.png | Campground |
+-----------------------+-----------------------+
| .. image:: waves.png | Lake |
+-----------------------+-----------------------+
| .. image:: peak.png | Mountain |
+-----------------------+-----------------------+
There must be blank lines before the caption paragraph and before the
legend. To specify a legend without a caption, use an empty comment
("..") in place of the caption.
The "figure" directive supports all options of the "image" directive. These options (except align) are passed on
to the contained image.
align"left", "center", or "right"
The horizontal alignment of the figure, allowing the image to
float and have the text flow around it. The specific behaviour
depends upon the browser or rendering software used.
In addition, the following options are recognized:
The width of the figure.
Limits the horizontal space used by the figure.
A special value of "image" is allowed, in which case the
included image's actual width is used (requires the Python Imaging
Library). If the image file is not found or the required software is
unavailable, this option is ignored.
A topic is like a block quote with a title, or a self-contained
section with no subsections. Use the "topic" directive to indicate a
self-contained idea that is separate from the flow of the document.
Topics may occur anywhere a section or transition may occur. Body
elements and topics may not contain nested topics.
The directive's sole argument is interpreted as the topic title; the
next line must be blank. All subsequent lines make up the topic body,
interpreted as body elements. For example:
.. topic:: Topic Title
Subsequent indented lines comprise
the body of the topic, and are
interpreted as body elements.
Sidebars are like miniature, parallel documents that occur inside
other documents, providing related or reference material. A sidebar
is typically offset by a border and "floats" to the side of the page;
the document's main text may flow around it. Sidebars can also be
likened to super-footnotes; their content is outside of the flow of
the document's main text.
Sidebars may occur anywhere a section or transition may occur. Body
elements (including sidebars) may not contain nested sidebars.
The directive's sole argument is interpreted as the sidebar title,
which may be followed by a subtitle option (see below); the next line
must be blank. All subsequent lines make up the sidebar body,
interpreted as body elements. For example:
.. sidebar:: Optional Sidebar Title
:subtitle: Optional Sidebar Subtitle
Subsequent indented lines comprise
the body of the sidebar, and are
interpreted as body elements.
Recognizes the common options class and name as well as
The "line-block" directive constructs an element where line breaks and
initial indentation is significant and inline markup is supported. It
is equivalent to a parsed literal block with different rendering:
typically in an ordinary serif typeface instead of a
typewriter/monospaced face, and not automatically indented. (Have the
line-block directive begin a block quote to get an indented line
block.) Line blocks are useful for address blocks and verse (poetry,
song lyrics), where the structure of lines is significant. For
example, here's a classic:
"To Ma Own Beloved Lassie: A Poem on her 17th Birthday", by
Ewan McTeagle (for Lassie O'Shea):
.. line-block::
Lend us a couple of bob till Thursday.
I'm absolutely skint.
But I'm expecting a postal order and I can pay you back
as soon as it comes.
Love, Ewan.
Unlike an ordinary literal block, the "parsed-literal" directive
constructs a literal block where the text is parsed for inline markup.
It is equivalent to a line block with different rendering:
typically in a typewriter/monospaced typeface, like an ordinary
literal block. Parsed literal blocks are useful for adding hyperlinks
to code examples.
However, care must be taken with the text, because inline markup is
recognized and there is no protection from parsing. Backslash-escapes
may be necessary to prevent unintended parsing. And because the
markup characters are removed by the parser, care must also be taken
with vertical alignment. Parsed "ASCII art" is tricky, and extra
whitespace may be necessary.
For example, all the element names in this content model are links:
The "code" directive constructs a literal block. If the code language is
specified, the content is parsed by the Pygments syntax highlighter and
tokens are stored in nested inline elements with class arguments
according to their syntactic category. The actual highlighting requires
a custom style-sheet, see the sandbox/stylesheets for examples.
For example, the content of the following directive
.. code:: python
:number-lines:
def my_function():
"just a test"
print(8/2)
is parsed and marked up as Python source code.
The parsing can be turned off with the syntax_highlight configuration
setting and command line option or by specifying the language as
class option instead of directive argument.
This also avoids warnings when Pygments is not installed or the language
is not in the supported languages and markup formats.
For code in external files, use the "include" directive with the
code option. For inline code, use the "code" role.
Recognizes the common options class and name as well as
The "math" directive inserts blocks with mathematical content
(display formulas, equations) into the document. The input format is
LaTeX math syntax with support for Unicode symbols, for example:
Support is limited to a subset of LaTeX math by the conversion
required for many output formats. For HTML, the math_output
configuration setting (or the corresponding --math-output
command line option) select between alternative output formats with
different subsets of supported elements. If a writer does not
support math typesetting, the content is inserted verbatim.
rubric n. 1. a title, heading, or the like, in a manuscript,
book, statute, etc., written or printed in red or otherwise
distinguished from the rest of the text. ...
—Random House Webster's College Dictionary, 1991
The "rubric" directive inserts a "rubric" element into the document
tree. A rubric is like an informal heading that doesn't correspond to
the document's structure.
A pull-quote is a small selection of text "pulled out and quoted",
typically in a larger typeface. Pull-quotes are used to attract
attention, especially in long articles.
The "pull-quote" directive produces a "pull-quote"-class block quote.
See Epigraph above for an analogous example.
The "compound" directive is used to create a compound paragraph, which
is a single logical paragraph containing multiple physical body
elements such as simple paragraphs, literal blocks, tables, lists,
etc., instead of directly containing text and inline elements. For
example:
.. compound::
The 'rm' command is very dangerous. If you are logged
in as root and enter ::
cd /
rm -rf *
you will erase the entire contents of your file system.
In the example above, a literal block is "embedded" within a sentence
that begins in one physical paragraph and ends in another.
Compound paragraphs are typically rendered as multiple distinct text
blocks, with the possibility of variations to emphasize their logical
unity:
If paragraphs are rendered with a first-line indent, only the first
physical paragraph of a compound paragraph should have that indent
-- second and further physical paragraphs should omit the indents;
vertical spacing between physical elements may be reduced;
The "container" directive surrounds its contents (arbitrary body
elements) with a generic block-level "container" element.
Combined with the optional argument, this is an
extension mechanism for users & applications. For example:
.. container:: custom
This paragraph might be rendered in a custom way.
Parsing the above results in the following pseudo-XML:
<container classes="custom">
<paragraph>
This paragraph might be rendered in a custom way.
The "container" directive is the equivalent of HTML's <div>
element. It may be used to group a sequence of elements for user- or
application-specific purposes.
Formal tables need more structure than the reStructuredText table syntax
supplies. Tables may be given titles with the "table" directive.
Sometimes reStructuredText tables are inconvenient to write, or table
data in a standard format is readily available. The "csv-table"
directive supports CSV [8] data.
Sets the width of the table to the specified length or percentage
of the line width. If omitted, the renderer determines the width
of the table based on its contents or the column widths.
The "csv-table" directive is used to create a table from CSV
(comma-separated values) [8] data. The data may be internal
(an integral part of the document) or external (a separate file).
Block markup and inline markup within cells is supported.
Line ends are recognized within quoted cells.
There is no support for checking that the number of columns in each
row is the same. The directive automatically adds empty entries at
the end of short rows.
Example:
.. csv-table:: Frozen Delights!
:header: "Treat", "Quantity", "Description"
:widths: 15, 10, 30
"Albatross", 2.99, "On a stick!"
"Crunchy Frog", 1.49, "If we took the bones out,
it wouldn't be crunchy, now would it?"
"Gannet Ripple", 1.99, "On a stick!"
Recognizes the common options class and name as well as
align"left", "center", or "right"
The horizontal alignment of the table. (New in Docutils 0.13)
The character used to separate data fields.
The special values "tab" and "space" are converted to the respective
whitespace characters. [9]
Defaults to "," (comma).
A character used to escape the delimiter or quote characters from
the CSV parser. The default is no escape character -- fields may
contain delimiter or newline characters if they are quoted, two quote
characters stand for a literal one, e.g., """Hi!"", he said.".
Supplemental data for the table header, added independently of and
before any header-rows from the main CSV data. Must use the
same CSV format as the main CSV data. [10]
Sets the width of the table to the specified length or percentage
of the line width. If omitted, the renderer determines the width
of the table based on its contents or the column widths.
(This is an initial implementation; further ideas may be implemented
in the future.)
The "list-table" directive is used to create a table from data in a
uniform two-level bullet list. "Uniform" means that each sublist
(second-level list) must contain the same number of list items.
Example:
.. list-table:: Frozen Delights!
:widths: 15 10 30
:header-rows: 1
* - Treat
- Quantity
- Description
* - Albatross
- 2.99
- On a stick!
* - Crunchy Frog
- 1.49
- If we took the bones out, it wouldn't be
crunchy, now would it?
* - Gannet Ripple
- 1.99
- On a stick!
Recognizes the common options class and name as well as
align"left", "center", or "right"
The horizontal alignment of the table.
(New in Docutils 0.13)
Sets the width of the table to the specified length or percentage
of the line width. If omitted, the renderer determines the width
of the table based on its contents or the column widths.
The "contents" directive generates a table of contents (TOC) in
a <topic> element. Topics, and therefore tables of contents,
may occur anywhere a section or transition may occur.
Body elements and topics may not contain tables of contents.
Here's the directive in its simplest form:
.. contents::
Language-dependent boilerplate text will be used for the title. The
English default title text is "Contents".
An explicit title may be specified:
.. contents:: Table of Contents
The title may span lines, although it is not recommended:
.. contents:: Here's a very long Table of
Contents title
Directive options may be specified using a field list:
.. contents:: Table of Contents
:depth: 2
If the default title is to be used, the options field list may begin
on the same line as the directive marker:
.. contents:: :depth: 2
The "contents" directive recognizes the common option
class as well as
backlinks"entry" or "top" or "none"
Generate links from section headers back to the table of contents
entries, the table of contents itself, or generate no back-links.
Generate a local table of contents. Entries will only include
subsections of the section in which the directive is given. If no
explicit title is given, the table of contents will not be titled.
The "sectnum" (or "section-numbering") directive automatically numbers
sections and subsections in a document (if not disabled by the
--no-section-numbering command line option or the sectnum_xform
configuration setting).
Section numbers are of the "multiple enumeration" form, where each
level has a number, separated by periods. For example, the title of section
1, subsection 2, subsubsection 3 would have "1.2.3" prefixed.
The directive does its work in two passes: the initial parse
and a transform. During the initial parse, a <pending> element is
generated which acts as a placeholder, storing any options internally.
At a later stage in the processing, the <pending> element triggers a
transform, which adds section numbers to titles. Section numbers are
enclosed in a <generated> element, and titles have their auto attribute
set to "1".
The "sectnum" directive recognizes the following options:
An arbitrary string that is prefixed to the automatically
generated section numbers. It may be something like "3.2.", which
will produce "3.2.1", "3.2.2", "3.2.2.1", and so on. Note that
any separating punctuation (in the example, a period, ".") must be
explicitly provided. The default is no prefix.
The value that will be used for the first section number.
Combined with prefix, this may be used to force the right
numbering for a document split over several source files. The
default is 1.
The "header" and "footer" directives create document decorations,
useful for page navigation, notes, time/datestamp, etc. For example:
.. header:: This space for rent.
This will add a paragraph to the document header, which will appear at
the top of the generated web page or at the top of every printed page.
These directives may be used multiple times, cumulatively. There is
currently support for only one header and footer.
In addition to the use of these directives to populate header and
footer content, content may also be added automatically by the
processing system. For example, if certain runtime settings are
enabled, the document footer is populated with processing information
such as a datestamp, a link to the Docutils website, etc.
The "target-notes" directive creates a footnote for each external
target in the text, and corresponding footnote references after each
reference. For every explicit target (of the form, .. _target name: URL) in the text, a footnote will be generated containing the
visible URL as content.
The "replace" directive is used to indicate replacement text for a
substitution reference. It may be used within substitution
definitions only. For example, this directive can be used to expand
abbreviations:
.. |reST| replace:: reStructuredText
Yes, |reST| is a long word, so I can't blame anyone for wanting to
abbreviate it.
As reStructuredText doesn't support nested inline markup, the only way
to create a reference with styled text is to use substitutions with
the "replace" directive:
I recommend you try |Python|_.
.. |Python| replace:: Python, *the* best language around
.. _Python: https://www.python.org/
The "unicode" directive converts Unicode character codes (numerical
values) to characters, and may be used in substitution definitions
only.
The arguments, separated by spaces, can be:
character codes as
decimal numbers or
hexadecimal numbers, prefixed by 0x, x, \x, U+,
u, or \u or as XML-style hexadecimal character entities,
e.g. ᨫ
text, which is used as-is.
Text following " .. " is a comment and is ignored. The spaces between
the arguments are ignored and thus do not appear in the output.
Hexadecimal codes are case-insensitive.
For example, the following text:
Copyright |copy| 2003, |BogusMegaCorp (TM)| |---|
all rights reserved.
.. |copy| unicode:: 0xA9 .. copyright sign
.. |BogusMegaCorp (TM)| unicode:: BogusMegaCorp U+2122
.. with trademark sign
.. |---| unicode:: U+02014 .. em dash
:trim:
The "date" directive generates the current local date and inserts it
into the document as text. This directive may be used in substitution
definitions only.
The optional directive content is interpreted as the desired date
format, using the same codes as Python's time.strftime() function. The
default format is "%Y-%m-%d" (ISO 8601 date), but time fields can also
be used. Examples:
.. |date| date::
.. |time| date:: %H:%M
Today's date is |date|.
This document was generated on |date| at |time|.
The "include" directive reads a text file. The directive argument is
the path to the file to be included, relative to the document containing
the directive. Unless the options literal, code, or parser
are given, the file is parsed in the current document's context at the
point of the directive. For example:
This first example will be parsed at the document level, and can
thus contain any construct, including section headers.
.. include:: inclusion.rst
Back in the main document.
This second example will be parsed in a block quote context.
Therefore it may only contain body elements. It may not
contain section headers.
.. include:: inclusion.rst
If an included document fragment contains section structure, the title
adornments must match those of the master document.
Standard data files intended for inclusion in reStructuredText
documents are distributed with the Docutils source code, located in
the "docutils" package in the docutils/parsers/rst/include
directory. To access these files, use the special syntax for standard
"include" data files, angle brackets around the file name:
Number of spaces for hard tab expansion.
Must be a positive integer, except for literal inclusions and code,
where a negative value prevents expansion of hard tabs.
Defaults to the tab_width configuration setting.
With code or literal the common options class and name
are recognized as well.
Combining start-line/end-line and start-after/end-before
is possible. The text markers will be searched in the specified lines
(further limiting the included content).
The "raw" directive indicates non-reStructuredText data that is to be
passed untouched to the Writer. The names of the output formats are
given in the directive arguments. The interpretation of the raw data
is up to the Writer. A Writer may ignore any raw output not matching
its format.
For example, the following input would be passed untouched by an HTML
writer:
.. raw:: html
<hr width=50 size=10>
A LaTeX Writer could insert the following raw content into its
output stream:
.. raw:: latex
\setlength{\parindent}{0pt}
Raw data can also be read from an external file, specified in the
file or url directive option.
In this case, the content block must be empty.
For example:
one or more, required
(class names / attribute values)
Directive Options:
none
Directive Content:
Optional. If present, it is interpreted as body
elements.
The "class" directive sets the classes attribute value on its content
or on the first immediately following [11] non-comment element [12].
The directive argument consists of one or more space-separated class
names. The names are transformed to conform to the regular expression
[a-z](-?[a-z0-9]+)* (see Identifier Normalization below).
Examples:
.. class:: special
This is a "special" paragraph.
.. class:: exceptional remarkable
An Exceptional Section
======================
This is an ordinary paragraph.
.. class:: multiple
First paragraph.
Second paragraph.
The text above is parsed and transformed into this doctree fragment:
<paragraph classes="special">
This is a "special" paragraph.
<section classes="exceptional remarkable">
<title>
An Exceptional Section
<paragraph>
This is an ordinary paragraph.
<paragraph classes="multiple">
First paragraph.
<paragraph classes="multiple">
Second paragraph.
Identifier Normalization
Docutils normalizes class names and identifiers to conform
to the regular expression "[a-z](-?[a-z0-9]+)*" by converting
alphabetic characters to lowercase,
accented characters to the base character,
non-alphanumeric characters to hyphens,
consecutive hyphens into one hyphen
and stripping
leading hyphens and number characters, and
trailing hyphens.
For example "Rot.Gelb&Grün:+2008" becomes "rot-gelb-grun-2008" and
"1000_Steps!" becomes "steps".
The "role" directive dynamically creates a custom interpreted text
role and registers it with the parser. This means that after
declaring a role like this:
.. role:: custom
the document may use the new "custom" role:
An example of using :custom:`interpreted text`
This will be parsed into the following document tree fragment:
<paragraph>
An example of using
<inline classes="custom">
interpreted text
Role names are case insensitive and must conform to the rules of
simple reference names (but do not share a namespace with
hyperlinks, footnotes, and citations).
The new role may be based on an existing role, specified as a second
argument in parentheses (whitespace optional):
.. role:: raw-role(raw)
:format: html latex
:raw-role:`raw text`
If no base role is explicitly specified, a generic custom role is
automatically used. Subsequent interpreted text will produce an
<inline> element with a classes attribute, as in the first
example above.
Depending on the base role, the following options may be recognized by the
"role" directive:
Set the classes attribute value on the element produced
when the custom interpreted text role is used.
Default value is the directive argument (role name).
For example
.. role:: custom
:class: special
:custom:`interpreted text`
is parsed as
<paragraph>
<inline classes="special">
interpreted text
The "class" option is recognized with all interpreted text roles.
formatspace-separated list of output format names (writer names)
The "default-role" directive sets the default interpreted text role,
the role that is used for interpreted text without an explicit role.
For example, after setting the default role like this:
.. default-role:: subscript
any subsequent use of implicit-role interpreted text in the document
will use the "subscript" role:
An example of a `default` role.
This will be parsed into the following document tree fragment:
<paragraph>
An example of a
<subscript>
default
role.
Custom roles may be used (see the "role" directive above), but it
must have been declared in a document before it can be set as the
default role. See the reStructuredText Interpreted Text Roles
document for details of built-in roles.
The directive may be used without an argument to restore the initial
default interpreted text role, which is application-dependent. The
initial default interpreted text role of the standard reStructuredText
parser is "title-reference".
The "meta" directive is used to specify metadata[14] to be stored
in, e.g., HTML meta elements or as ODT file properties. The
LaTeX writer passes it to the pdfinfo option of the hyperref
package. If an output format does not support "invisible" metadata,
content is silently dropped by the writer.
Within the directive block, a flat field list provides the syntax for
metadata. The field name becomes the contents of the "name" attribute
of the META tag, and the field body (interpreted as a single string
without inline markup) becomes the contents of the "content"
attribute. For example:
.. meta::
:description: The reStructuredText plaintext markup language
:keywords: plaintext, markup language
Support for other META attributes ("http-equiv", "scheme", "lang",
"dir") are provided through field arguments, which must be of the form
"attr=value":
.. meta::
:description lang=en: An amusing story
:description lang=fr: Une histoire amusante
The "title" directive specifies the document title as metadata, which
does not become part of the document body. It overrides the
document-supplied document title and the "title" configuration
setting.
This directive is provided for test purposes only. (Nobody is
expected to type in a name that long!) It is converted into a
level-1 (info) system message showing the directive data, possibly
followed by a literal block containing the rest of the directive
block.
Handling of values without unit depends on the writer/output format.
See the writer specific documentation in the user doc for details.
path:
local filesystem path
Newlines are removed.
The root_prefix configuration setting can be used to tell Docutils
to interpret paths starting with "/" relative to a "project directory".
percentage:
number followed by the percent sign '%'
Percentage values are relative to other values, depending on the
context in which they occur.