2008-03-15 04:06:04 -05:00
|
|
|
.. highlight:: rest
|
|
|
|
|
|
|
|
Miscellaneous markup
|
|
|
|
====================
|
|
|
|
|
2009-02-15 13:08:31 -06:00
|
|
|
.. _metadata:
|
2009-02-15 04:38:23 -06:00
|
|
|
|
2008-03-15 04:06:04 -05:00
|
|
|
File-wide metadata
|
|
|
|
------------------
|
|
|
|
|
|
|
|
reST has the concept of "field lists"; these are a sequence of fields marked up
|
|
|
|
like this::
|
|
|
|
|
2010-03-01 07:37:31 -06:00
|
|
|
:fieldname: Field content
|
2008-03-15 04:06:04 -05:00
|
|
|
|
2011-01-03 17:08:38 -06:00
|
|
|
A field list near the top of a file is parsed by docutils as the "docinfo"
|
2010-03-01 07:37:31 -06:00
|
|
|
which is normally used to record the author, date of publication and other
|
2011-01-03 17:08:38 -06:00
|
|
|
metadata. *In Sphinx*, a field list preceding any other markup is moved from
|
|
|
|
the docinfo to the Sphinx environment as document metadata and is not displayed
|
|
|
|
in the output; a field list appearing after the document title will be part of
|
|
|
|
the docinfo as normal and will be displayed in the output.
|
2008-03-15 04:06:04 -05:00
|
|
|
|
2008-06-12 16:56:06 -05:00
|
|
|
At the moment, these metadata fields are recognized:
|
|
|
|
|
|
|
|
``tocdepth``
|
|
|
|
The maximum depth for a table of contents of this file.
|
|
|
|
|
|
|
|
.. versionadded:: 0.4
|
2008-03-15 04:06:04 -05:00
|
|
|
|
|
|
|
``nocomments``
|
|
|
|
If set, the web application won't display a comment form for a page generated
|
|
|
|
from this source file.
|
|
|
|
|
2010-02-25 15:49:54 -06:00
|
|
|
``orphan``
|
|
|
|
If set, warnings about this file not being included in any toctree will be
|
|
|
|
suppressed.
|
|
|
|
|
|
|
|
.. versionadded:: 1.0
|
|
|
|
|
2008-03-15 04:06:04 -05:00
|
|
|
|
|
|
|
Meta-information markup
|
|
|
|
-----------------------
|
|
|
|
|
2010-04-17 03:39:51 -05:00
|
|
|
.. rst:directive:: .. sectionauthor:: name <email>
|
2008-03-15 04:06:04 -05:00
|
|
|
|
|
|
|
Identifies the author of the current section. The argument should include
|
|
|
|
the author's name such that it can be used for presentation and email
|
|
|
|
address. The domain name portion of the address should be lower case.
|
|
|
|
Example::
|
|
|
|
|
|
|
|
.. sectionauthor:: Guido van Rossum <guido@python.org>
|
|
|
|
|
|
|
|
By default, this markup isn't reflected in the output in any way (it helps
|
|
|
|
keep track of contributions), but you can set the configuration value
|
|
|
|
:confval:`show_authors` to True to make them produce a paragraph in the
|
|
|
|
output.
|
2008-05-03 13:14:13 -05:00
|
|
|
|
|
|
|
|
2010-04-17 03:39:51 -05:00
|
|
|
.. rst:directive:: .. codeauthor:: name <email>
|
2010-03-01 07:22:14 -06:00
|
|
|
|
2010-04-17 03:39:51 -05:00
|
|
|
The :rst:dir:`codeauthor` directive, which can appear multiple times, names the
|
|
|
|
authors of the described code, just like :rst:dir:`sectionauthor` names the
|
2010-03-01 07:22:14 -06:00
|
|
|
author(s) of a piece of documentation. It too only produces output if the
|
|
|
|
:confval:`show_authors` configuration value is True.
|
|
|
|
|
|
|
|
|
2009-02-19 14:56:34 -06:00
|
|
|
.. _tags:
|
|
|
|
|
|
|
|
Including content based on tags
|
|
|
|
-------------------------------
|
|
|
|
|
2010-04-17 03:39:51 -05:00
|
|
|
.. rst:directive:: .. only:: <expression>
|
2009-02-19 14:56:34 -06:00
|
|
|
|
|
|
|
Include the content of the directive only if the *expression* is true. The
|
|
|
|
expression should consist of tags, like this::
|
|
|
|
|
|
|
|
.. only:: html and draft
|
|
|
|
|
|
|
|
Undefined tags are false, defined tags (via the ``-t`` command-line option or
|
|
|
|
within :file:`conf.py`) are true. Boolean expressions, also using
|
|
|
|
parentheses (like ``html and (latex or draft)`` are supported.
|
|
|
|
|
|
|
|
The format of the current builder (``html``, ``latex`` or ``text``) is always
|
|
|
|
set as a tag.
|
|
|
|
|
|
|
|
.. versionadded:: 0.6
|
|
|
|
|
|
|
|
|
2008-05-03 13:14:13 -05:00
|
|
|
Tables
|
|
|
|
------
|
|
|
|
|
2010-03-01 07:53:30 -06:00
|
|
|
Use :ref:`standard reStructuredText tables <rst-tables>`. They work fine in
|
|
|
|
HTML output, however there are some gotchas when using tables in LaTeX: the
|
|
|
|
column width is hard to determine correctly automatically. For this reason, the
|
|
|
|
following directive exists:
|
2008-05-03 13:14:13 -05:00
|
|
|
|
2010-04-17 03:39:51 -05:00
|
|
|
.. rst:directive:: .. tabularcolumns:: column spec
|
2008-05-03 13:14:13 -05:00
|
|
|
|
|
|
|
This directive gives a "column spec" for the next table occurring in the
|
|
|
|
source file. The spec is the second argument to the LaTeX ``tabulary``
|
|
|
|
package's environment (which Sphinx uses to translate tables). It can have
|
|
|
|
values like ::
|
|
|
|
|
|
|
|
|l|l|l|
|
|
|
|
|
|
|
|
which means three left-adjusted, nonbreaking columns. For columns with
|
|
|
|
longer text that should automatically be broken, use either the standard
|
|
|
|
``p{width}`` construct, or tabulary's automatic specifiers:
|
|
|
|
|
|
|
|
+-----+------------------------------------------+
|
|
|
|
|``L``| ragged-left column with automatic width |
|
|
|
|
+-----+------------------------------------------+
|
|
|
|
|``R``| ragged-right column with automatic width |
|
|
|
|
+-----+------------------------------------------+
|
|
|
|
|``C``| centered column with automatic width |
|
|
|
|
+-----+------------------------------------------+
|
|
|
|
|``J``| justified column with automatic width |
|
|
|
|
+-----+------------------------------------------+
|
|
|
|
|
|
|
|
The automatic width is determined by rendering the content in the table, and
|
|
|
|
scaling them according to their share of the total width.
|
|
|
|
|
2008-05-03 15:15:25 -05:00
|
|
|
By default, Sphinx uses a table layout with ``L`` for every column.
|
|
|
|
|
2008-05-04 12:57:11 -05:00
|
|
|
.. versionadded:: 0.3
|
2008-05-04 02:43:09 -05:00
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
2011-01-03 16:34:57 -06:00
|
|
|
Tables that contain list-like elements such as object descriptions,
|
|
|
|
blockquotes or any kind of lists cannot be set out of the box with
|
|
|
|
``tabulary``. They are therefore set with the standard LaTeX ``tabular``
|
|
|
|
environment if you don't give a ``tabularcolumns`` directive. If you do, the
|
|
|
|
table will be set with ``tabulary``, but you must use the ``p{width}``
|
|
|
|
construct for the columns that contain these elements.
|
|
|
|
|
|
|
|
Literal blocks do not work with ``tabulary`` at all, so tables containing a
|
|
|
|
literal block are always set with ``tabular``. Also, the verbatim
|
|
|
|
environment used for literal blocks only works in ``p{width}`` columns, which
|
|
|
|
means that by default, Sphinx generates such column specs for such tables.
|
|
|
|
Use the :rst:dir:`tabularcolumns` directive to get finer control over such
|
|
|
|
tables.
|