From 35e26230fd61042bb8b8a28873d12d2d20a9d370 Mon Sep 17 00:00:00 2001 From: Georg Brandl Date: Sun, 5 Aug 2007 12:26:55 +0000 Subject: [PATCH] Other minor fixes. --- Doc-26/library/codecs.rst | 49 ++++++++++++++------------- Doc-26/library/datetime.rst | 4 +-- Doc-26/library/functools.rst | 38 ++++++++++----------- Doc-26/library/time.rst | 65 +----------------------------------- Doc-26/license.rst | 10 +++--- Doc-3k/library/codecs.rst | 49 ++++++++++++++------------- Doc-3k/library/datetime.rst | 4 +-- Doc-3k/library/functools.rst | 38 ++++++++++----------- Doc-3k/license.rst | 10 +++--- sphinx/style/default.css | 5 +++ sphinx/style/traditional.css | 5 +++ sphinx/writer.py | 4 +-- 12 files changed, 115 insertions(+), 166 deletions(-) diff --git a/Doc-26/library/codecs.rst b/Doc-26/library/codecs.rst index 7a45f5dbf..e86999e1f 100644 --- a/Doc-26/library/codecs.rst +++ b/Doc-26/library/codecs.rst @@ -734,24 +734,24 @@ Encodings and Unicode Unicode strings are stored internally as sequences of codepoints (to be precise as :ctype:`Py_UNICODE` arrays). Depending on the way Python is compiled (either -via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with -the former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit -data type. Once a Unicode object is used outside of CPU and memory, CPU -endianness and how these arrays are stored as bytes become an issue. -Transforming a unicode object into a sequence of bytes is called encoding and -recreating the unicode object from the sequence of bytes is known as decoding. -There are many different methods for how this transformation can be done (these -methods are also called encodings). The simplest method is to map the codepoints -0-255 to the bytes ``0x0``\ -\ ``0xff``. This means that a unicode object that -contains codepoints above ``U+00FF`` can't be encoded with this method (which -is called ``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise -a :exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError: -'latin-1' codec can't encode character u'\u1234' in position 3: ordinal not in +via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with the +former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit data +type. Once a Unicode object is used outside of CPU and memory, CPU endianness +and how these arrays are stored as bytes become an issue. Transforming a +unicode object into a sequence of bytes is called encoding and recreating the +unicode object from the sequence of bytes is known as decoding. There are many +different methods for how this transformation can be done (these methods are +also called encodings). The simplest method is to map the codepoints 0-255 to +the bytes ``0x0``-``0xff``. This means that a unicode object that contains +codepoints above ``U+00FF`` can't be encoded with this method (which is called +``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise a +:exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError: 'latin-1' +codec can't encode character u'\u1234' in position 3: ordinal not in range(256)``. There's another group of encodings (the so called charmap encodings) that choose a different subset of all unicode code points and how these codepoints are -mapped to the bytes ``0x0``\ -\ ``0xff.`` To see how this is done simply open +mapped to the bytes ``0x0``-``0xff``. To see how this is done simply open e.g. :file:`encodings/cp1252.py` (which is an encoding that is used primarily on Windows). There's a string constant with 256 characters that shows you which character is mapped to which byte value. @@ -824,8 +824,9 @@ sequence: ``0xef``, ``0xbb``, ``0xbf``) is written. As it's rather improbable that any charmap encoded file starts with these byte values (which would e.g. map to -LATIN SMALL LETTER I WITH DIAERESIS --- RIGHT-POINTING DOUBLE ANGLE QUOTATION -MARK --- INVERTED QUESTION MARK + | LATIN SMALL LETTER I WITH DIAERESIS + | RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK + | INVERTED QUESTION MARK in iso-8859-1), this increases the probability that a utf-8-sig encoding can be correctly guessed from the byte sequence. So here the BOM is not used to be able @@ -1152,14 +1153,14 @@ and :mod:`stringprep`. These RFCs together define a protocol to support non-ASCII characters in domain names. A domain name containing non-ASCII characters (such as -"www.Alliancefrançaise.nu") is converted into an ASCII-compatible encoding (ACE, -such as "www.xn--alliancefranaise-npb.nu"). The ACE form of the domain name is -then used in all places where arbitrary characters are not allowed by the -protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so on. This -conversion is carried out in the application; if possible invisible to the user: -The application should transparently convert Unicode domain labels to IDNA on -the wire, and convert back ACE labels to Unicode before presenting them to the -user. +``www.Alliancefrançaise.nu``) is converted into an ASCII-compatible encoding +(ACE, such as ``www.xn--alliancefranaise-npb.nu``). The ACE form of the domain +name is then used in all places where arbitrary characters are not allowed by +the protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so +on. This conversion is carried out in the application; if possible invisible to +the user: The application should transparently convert Unicode domain labels to +IDNA on the wire, and convert back ACE labels to Unicode before presenting them +to the user. Python supports this conversion in several ways: The ``idna`` codec allows to convert between Unicode and the ACE. Furthermore, the :mod:`socket` module diff --git a/Doc-26/library/datetime.rst b/Doc-26/library/datetime.rst index 62f033847..17c4c5343 100644 --- a/Doc-26/library/datetime.rst +++ b/Doc-26/library/datetime.rst @@ -473,8 +473,8 @@ Instance methods: .. method:: date.ctime() - Return a string representing the date, for example date(2002, 12, 4).ctime() == - 'Wed Dec 4 00:00:00 2002'. ``d.ctime()`` is equivalent to + Return a string representing the date, for example ``date(2002, 12, + 4).ctime() == 'Wed Dec 4 00:00:00 2002'``. ``d.ctime()`` is equivalent to ``time.ctime(time.mktime(d.timetuple()))`` on platforms where the native C :cfunc:`ctime` function (which :func:`time.ctime` invokes, but which :meth:`date.ctime` does not invoke) conforms to the C standard. diff --git a/Doc-26/library/functools.rst b/Doc-26/library/functools.rst index ed40174ef..6049b6161 100644 --- a/Doc-26/library/functools.rst +++ b/Doc-26/library/functools.rst @@ -73,25 +73,25 @@ The :mod:`functools` module defines the following function: wrapped=wrapped, assigned=assigned, updated=updated)`` as a function decorator when defining a wrapper function. For example:: - >>> def my_decorator(f): - ... @wraps(f) - ... def wrapper(*args, **kwds): - ... print 'Calling decorated function' - ... return f(*args, **kwds) - ... return wrapper - ... - >>> @my_decorator - ... def example(): - ... """Docstring""" - ... print 'Called example function' - ... - >>> example() - Calling decorated function - Called example function - >>> example.__name__ - 'example' - >>> example.__doc__ - 'Docstring' + >>> def my_decorator(f): + ... @wraps(f) + ... def wrapper(*args, **kwds): + ... print 'Calling decorated function' + ... return f(*args, **kwds) + ... return wrapper + ... + >>> @my_decorator + ... def example(): + ... """Docstring""" + ... print 'Called example function' + ... + >>> example() + Calling decorated function + Called example function + >>> example.__name__ + 'example' + >>> example.__doc__ + 'Docstring' Without the use of this decorator factory, the name of the example function would have been ``'wrapper'``, and the docstring of the original :func:`example` diff --git a/Doc-26/library/time.rst b/Doc-26/library/time.rst index 3ab16f5fd..8bcc6dda7 100644 --- a/Doc-26/library/time.rst +++ b/Doc-26/library/time.rst @@ -102,29 +102,12 @@ An explanation of some terminology and conventions is in order. +-------+-------------------+---------------------------------+ | 8 | :attr:`tm_isdst` | 0, 1 or -1; see below | +-------+-------------------+---------------------------------+ - | - | :attr:`tm_gmtoff` | offset from UTC/GMT in seconds | - | | | east of the Prime Meridian; see | - | | | below | - +-------+-------------------+---------------------------------+ - | - | :attr:`tm_zone` | time zone name; see below | - +-------+-------------------+---------------------------------+ Note that unlike the C structure, the month value is a range of 1-12, not 0-11. A year value will be handled as described under "Year 2000 (Y2K) issues" above. A ``-1`` argument as the daylight savings flag, passed to :func:`mktime` will usually result in the correct daylight savings state to be filled in. - To maintain backwards compatibility, the :attr:`tm_gmtoff` and :attr:`tm_zone` - attributes are not included in the visual representation of each - :class:`struct_time`, but they can be inspected as named, read-only attributes. - Since functions such as :func:`mktime` accept either a 9-tuple or a - :class:`struct_time`, to manually construct a time with specific values of these - attributes, first construct an 11-tuple using the normal 9-tuple extended to - include values for :attr:`tm_gmtoff` and :attr:`tm_zone` as the last two - elements, then pass this tuple to the :class:`struct_time` constructor. It is - also possible to omit :attr:`tm_zone` and to provide a 10-tuple to the - :class:`struct_time` constructor. - When a tuple with an incorrect length is passed to a function expecting a :class:`struct_time`, or having elements of the wrong type, a :exc:`TypeError` is raised. @@ -133,13 +116,9 @@ An explanation of some terminology and conventions is in order. The time value sequence was changed from a tuple to a :class:`struct_time`, with the addition of attribute names for the fields. - .. versionchanged:: 2.6 - The time value sequence was extended to provide the :attr:`tm_gmtoff` and - :attr:`tm_zone` attributes as described above. The module defines the following functions and data items: - .. data:: accept2dyear Boolean value indicating whether two-digit year values will be accepted. This @@ -249,25 +228,6 @@ The module defines the following functions and data items: The earliest date for which it can generate a time is platform-dependent. -.. function:: mktimetz(t) - - This function interprets times in arbitrary time zones, producing a value - indicating the number of seconds since the epoch for each time. It combines the - ability of :func:`mktime` to convert local times with the ability of - :func:`timegm` to convert GMT/UTC times, but is not constrained by the system's - current time zone, instead obtaining time zone information directly from its - argument where possible. Its argument is the :class:`struct_time` (which may - provide time zone information) or a 9-tuple (which does not, causing the - argument to be interpreted as a time in the GMT/UTC zone). It returns a - floating point number, for compatibility with :func:`time`. If the input value - cannot be represented as a valid time, either :exc:`OverflowError` or - :exc:`ValueError` will be raised (which depends on whether the invalid value is - caught by Python or the underlying C libraries). The earliest date for which it - can generate a time is platform-dependent. - - .. versionadded:: 2.6 - - .. function:: sleep(secs) Suspend execution for the given number of seconds. The argument may be a @@ -371,14 +331,6 @@ The module defines the following functions and data items: | ``%Y`` | Year with century as a decimal | | | | number. | | +-----------+--------------------------------+-------+ - | ``%z`` | Time zone offset indicating a | | - | | positive or negative time | | - | | difference from UTC/GMT of the | | - | | form +HHMM or -HHMM, where H | | - | | represents decimal hour digits | | - | | and M represents decimal | | - | | minute digits [00,59]. | | - +-----------+--------------------------------+-------+ | ``%Z`` | Time zone name (no characters | | | | if no time zone exists). | | +-----------+--------------------------------+-------+ @@ -463,20 +415,6 @@ The module defines the following functions and data items: the two calls. -.. function:: timegm(t) - - This is the inverse function of :func:`gmtime`. Its argument is a - :class:`struct_time` or full 9-tuple which expresses the time in *GMT/UTC* time, - not local time as expected by :func:`mktime`. It returns a floating point - number, for compatibility with :func:`time`. If the input value cannot be - represented as a valid time, either :exc:`OverflowError` or :exc:`ValueError` - will be raised (which depends on whether the invalid value is caught by Python - or the underlying C libraries). The earliest date for which it can generate a - time is platform-dependent. - - .. versionadded:: 2.6 - - .. data:: timezone The offset of the local (non-DST) timezone, in seconds west of UTC (negative in @@ -586,8 +524,7 @@ The module defines the following functions and data items: Module :mod:`calendar` General calendar-related functions. :func:`timegm` is the inverse of - :func:`gmtime` from this module, offering an alternative implementation of - :func:`timegm` from this module. + :func:`gmtime` from this module. .. rubric:: Footnotes diff --git a/Doc-26/license.rst b/Doc-26/license.rst index 474c0010a..a9165f43f 100644 --- a/Doc-26/license.rst +++ b/Doc-26/license.rst @@ -105,7 +105,7 @@ Terms and conditions for accessing or otherwise using Python ============================================================ -.. centered:: **PSF LICENSE AGREEMENT FOR PYTHON** |release| +.. centered:: PSF LICENSE AGREEMENT FOR PYTHON |release| #. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using Python @@ -150,10 +150,10 @@ Terms and conditions for accessing or otherwise using Python to be bound by the terms and conditions of this License Agreement. -.. centered:: **BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0** +.. centered:: BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0 -.. centered:: **BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1** +.. centered:: BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1 #. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the Individual or Organization @@ -195,7 +195,7 @@ Terms and conditions for accessing or otherwise using Python bound by the terms and conditions of this License Agreement. -.. centered:: **CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1** +.. centered:: CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1 #. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 @@ -260,7 +260,7 @@ Terms and conditions for accessing or otherwise using Python .. centered:: ACCEPT -.. centered:: **CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2** +.. centered:: CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2 Copyright © 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The Netherlands. All rights reserved. diff --git a/Doc-3k/library/codecs.rst b/Doc-3k/library/codecs.rst index 930b9b9f4..38264dfdf 100644 --- a/Doc-3k/library/codecs.rst +++ b/Doc-3k/library/codecs.rst @@ -778,24 +778,24 @@ Encodings and Unicode Unicode strings are stored internally as sequences of codepoints (to be precise as :ctype:`Py_UNICODE` arrays). Depending on the way Python is compiled (either -via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with -the former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit -data type. Once a Unicode object is used outside of CPU and memory, CPU -endianness and how these arrays are stored as bytes become an issue. -Transforming a unicode object into a sequence of bytes is called encoding and -recreating the unicode object from the sequence of bytes is known as decoding. -There are many different methods for how this transformation can be done (these -methods are also called encodings). The simplest method is to map the codepoints -0-255 to the bytes ``0x0``\ -\ ``0xff``. This means that a unicode object that -contains codepoints above ``U+00FF`` can't be encoded with this method (which -is called ``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise -a :exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError: -'latin-1' codec can't encode character u'\u1234' in position 3: ordinal not in +via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with the +former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit data +type. Once a Unicode object is used outside of CPU and memory, CPU endianness +and how these arrays are stored as bytes become an issue. Transforming a +unicode object into a sequence of bytes is called encoding and recreating the +unicode object from the sequence of bytes is known as decoding. There are many +different methods for how this transformation can be done (these methods are +also called encodings). The simplest method is to map the codepoints 0-255 to +the bytes ``0x0``-``0xff``. This means that a unicode object that contains +codepoints above ``U+00FF`` can't be encoded with this method (which is called +``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise a +:exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError: 'latin-1' +codec can't encode character u'\u1234' in position 3: ordinal not in range(256)``. There's another group of encodings (the so called charmap encodings) that choose a different subset of all unicode code points and how these codepoints are -mapped to the bytes ``0x0``\ -\ ``0xff.`` To see how this is done simply open +mapped to the bytes ``0x0``-``0xff``. To see how this is done simply open e.g. :file:`encodings/cp1252.py` (which is an encoding that is used primarily on Windows). There's a string constant with 256 characters that shows you which character is mapped to which byte value. @@ -868,8 +868,9 @@ sequence: ``0xef``, ``0xbb``, ``0xbf``) is written. As it's rather improbable that any charmap encoded file starts with these byte values (which would e.g. map to -LATIN SMALL LETTER I WITH DIAERESIS --- RIGHT-POINTING DOUBLE ANGLE QUOTATION -MARK --- INVERTED QUESTION MARK + | LATIN SMALL LETTER I WITH DIAERESIS + | RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK + | INVERTED QUESTION MARK in iso-8859-1), this increases the probability that a utf-8-sig encoding can be correctly guessed from the byte sequence. So here the BOM is not used to be able @@ -1168,14 +1169,14 @@ and :mod:`stringprep`. These RFCs together define a protocol to support non-ASCII characters in domain names. A domain name containing non-ASCII characters (such as -"www.Alliancefrançaise.nu") is converted into an ASCII-compatible encoding (ACE, -such as "www.xn--alliancefranaise-npb.nu"). The ACE form of the domain name is -then used in all places where arbitrary characters are not allowed by the -protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so on. This -conversion is carried out in the application; if possible invisible to the user: -The application should transparently convert Unicode domain labels to IDNA on -the wire, and convert back ACE labels to Unicode before presenting them to the -user. +``www.Alliancefrançaise.nu``) is converted into an ASCII-compatible encoding +(ACE, such as ``www.xn--alliancefranaise-npb.nu``). The ACE form of the domain +name is then used in all places where arbitrary characters are not allowed by +the protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so +on. This conversion is carried out in the application; if possible invisible to +the user: The application should transparently convert Unicode domain labels to +IDNA on the wire, and convert back ACE labels to Unicode before presenting them +to the user. Python supports this conversion in several ways: The ``idna`` codec allows to convert between Unicode and the ACE. Furthermore, the :mod:`socket` module diff --git a/Doc-3k/library/datetime.rst b/Doc-3k/library/datetime.rst index 62f033847..17c4c5343 100644 --- a/Doc-3k/library/datetime.rst +++ b/Doc-3k/library/datetime.rst @@ -473,8 +473,8 @@ Instance methods: .. method:: date.ctime() - Return a string representing the date, for example date(2002, 12, 4).ctime() == - 'Wed Dec 4 00:00:00 2002'. ``d.ctime()`` is equivalent to + Return a string representing the date, for example ``date(2002, 12, + 4).ctime() == 'Wed Dec 4 00:00:00 2002'``. ``d.ctime()`` is equivalent to ``time.ctime(time.mktime(d.timetuple()))`` on platforms where the native C :cfunc:`ctime` function (which :func:`time.ctime` invokes, but which :meth:`date.ctime` does not invoke) conforms to the C standard. diff --git a/Doc-3k/library/functools.rst b/Doc-3k/library/functools.rst index 78f111013..34a6d02cd 100644 --- a/Doc-3k/library/functools.rst +++ b/Doc-3k/library/functools.rst @@ -85,25 +85,25 @@ The :mod:`functools` module defines the following function: wrapped=wrapped, assigned=assigned, updated=updated)`` as a function decorator when defining a wrapper function. For example:: - >>> def my_decorator(f): - ... @wraps(f) - ... def wrapper(*args, **kwds): - ... print 'Calling decorated function' - ... return f(*args, **kwds) - ... return wrapper - ... - >>> @my_decorator - ... def example(): - ... """Docstring""" - ... print 'Called example function' - ... - >>> example() - Calling decorated function - Called example function - >>> example.__name__ - 'example' - >>> example.__doc__ - 'Docstring' + >>> def my_decorator(f): + ... @wraps(f) + ... def wrapper(*args, **kwds): + ... print 'Calling decorated function' + ... return f(*args, **kwds) + ... return wrapper + ... + >>> @my_decorator + ... def example(): + ... """Docstring""" + ... print 'Called example function' + ... + >>> example() + Calling decorated function + Called example function + >>> example.__name__ + 'example' + >>> example.__doc__ + 'Docstring' Without the use of this decorator factory, the name of the example function would have been ``'wrapper'``, and the docstring of the original :func:`example` diff --git a/Doc-3k/license.rst b/Doc-3k/license.rst index 474c0010a..a9165f43f 100644 --- a/Doc-3k/license.rst +++ b/Doc-3k/license.rst @@ -105,7 +105,7 @@ Terms and conditions for accessing or otherwise using Python ============================================================ -.. centered:: **PSF LICENSE AGREEMENT FOR PYTHON** |release| +.. centered:: PSF LICENSE AGREEMENT FOR PYTHON |release| #. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using Python @@ -150,10 +150,10 @@ Terms and conditions for accessing or otherwise using Python to be bound by the terms and conditions of this License Agreement. -.. centered:: **BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0** +.. centered:: BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0 -.. centered:: **BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1** +.. centered:: BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1 #. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the Individual or Organization @@ -195,7 +195,7 @@ Terms and conditions for accessing or otherwise using Python bound by the terms and conditions of this License Agreement. -.. centered:: **CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1** +.. centered:: CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1 #. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 @@ -260,7 +260,7 @@ Terms and conditions for accessing or otherwise using Python .. centered:: ACCEPT -.. centered:: **CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2** +.. centered:: CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2 Copyright © 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The Netherlands. All rights reserved. diff --git a/sphinx/style/default.css b/sphinx/style/default.css index f976672f2..39de529e7 100644 --- a/sphinx/style/default.css +++ b/sphinx/style/default.css @@ -638,6 +638,11 @@ p.admonition-title:after { content: ":"; } +div.body p.centered { + text-align: center; + margin-top: 25px; +} + table.docutils { border: 0; } diff --git a/sphinx/style/traditional.css b/sphinx/style/traditional.css index 0b8efdea3..ca9587867 100644 --- a/sphinx/style/traditional.css +++ b/sphinx/style/traditional.css @@ -547,6 +547,11 @@ p.admonition-title:after { content: ":"; } +div.body p.centered { + text-align: center; + margin-top: 25px; +} + table.docutils { border: 0; } diff --git a/sphinx/writer.py b/sphinx/writer.py index ff716faae..7b97f4990 100644 --- a/sphinx/writer.py +++ b/sphinx/writer.py @@ -174,9 +174,9 @@ class HTMLTranslator(BaseTranslator): pass def visit_centered(self, node): - self.body.append(self.starttag(node, 'center') + '') + self.body.append(self.starttag(node, 'p', CLASS="centered") + '') def depart_centered(self, node): - self.body.append('') + self.body.append('

') def visit_compact_paragraph(self, node): pass