[Python-checkins] r56752 - in doctools/trunk: Doc-26/library/codecs.rst Doc-26/library/datetime.rst Doc-26/library/functools.rst Doc-26/library/time.rst Doc-26/license.rst Doc-3k/library/codecs.rst Doc-3k/library/datetime.rst Doc-3k/library/functools.rst Doc-3k/license.rst sphinx/style/default.css sphinx/style/traditional.css sphinx/writer.py
georg.brandl
python-checkins at python.org
Sun Aug 5 14:26:56 CEST 2007
Author: georg.brandl
Date: Sun Aug 5 14:26:55 2007
New Revision: 56752
Modified:
doctools/trunk/Doc-26/library/codecs.rst
doctools/trunk/Doc-26/library/datetime.rst
doctools/trunk/Doc-26/library/functools.rst
doctools/trunk/Doc-26/library/time.rst
doctools/trunk/Doc-26/license.rst
doctools/trunk/Doc-3k/library/codecs.rst
doctools/trunk/Doc-3k/library/datetime.rst
doctools/trunk/Doc-3k/library/functools.rst
doctools/trunk/Doc-3k/license.rst
doctools/trunk/sphinx/style/default.css
doctools/trunk/sphinx/style/traditional.css
doctools/trunk/sphinx/writer.py
Log:
Other minor fixes.
Modified: doctools/trunk/Doc-26/library/codecs.rst
==============================================================================
--- doctools/trunk/Doc-26/library/codecs.rst (original)
+++ doctools/trunk/Doc-26/library/codecs.rst Sun Aug 5 14:26:55 2007
@@ -734,24 +734,24 @@
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 @@
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 @@
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
Modified: doctools/trunk/Doc-26/library/datetime.rst
==============================================================================
--- doctools/trunk/Doc-26/library/datetime.rst (original)
+++ doctools/trunk/Doc-26/library/datetime.rst Sun Aug 5 14:26:55 2007
@@ -473,8 +473,8 @@
.. 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.
Modified: doctools/trunk/Doc-26/library/functools.rst
==============================================================================
--- doctools/trunk/Doc-26/library/functools.rst (original)
+++ doctools/trunk/Doc-26/library/functools.rst Sun Aug 5 14:26:55 2007
@@ -73,25 +73,25 @@
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`
Modified: doctools/trunk/Doc-26/library/time.rst
==============================================================================
--- doctools/trunk/Doc-26/library/time.rst (original)
+++ doctools/trunk/Doc-26/library/time.rst Sun Aug 5 14:26:55 2007
@@ -102,29 +102,12 @@
+-------+-------------------+---------------------------------+
| 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 @@
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 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 @@
| ``%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 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 @@
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
Modified: doctools/trunk/Doc-26/license.rst
==============================================================================
--- doctools/trunk/Doc-26/license.rst (original)
+++ doctools/trunk/Doc-26/license.rst Sun Aug 5 14:26:55 2007
@@ -105,7 +105,7 @@
============================================================
-.. 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 @@
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 @@
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 @@
.. 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.
Modified: doctools/trunk/Doc-3k/library/codecs.rst
==============================================================================
--- doctools/trunk/Doc-3k/library/codecs.rst (original)
+++ doctools/trunk/Doc-3k/library/codecs.rst Sun Aug 5 14:26:55 2007
@@ -778,24 +778,24 @@
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 @@
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 @@
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
Modified: doctools/trunk/Doc-3k/library/datetime.rst
==============================================================================
--- doctools/trunk/Doc-3k/library/datetime.rst (original)
+++ doctools/trunk/Doc-3k/library/datetime.rst Sun Aug 5 14:26:55 2007
@@ -473,8 +473,8 @@
.. 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.
Modified: doctools/trunk/Doc-3k/library/functools.rst
==============================================================================
--- doctools/trunk/Doc-3k/library/functools.rst (original)
+++ doctools/trunk/Doc-3k/library/functools.rst Sun Aug 5 14:26:55 2007
@@ -85,25 +85,25 @@
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`
Modified: doctools/trunk/Doc-3k/license.rst
==============================================================================
--- doctools/trunk/Doc-3k/license.rst (original)
+++ doctools/trunk/Doc-3k/license.rst Sun Aug 5 14:26:55 2007
@@ -105,7 +105,7 @@
============================================================
-.. 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 @@
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 @@
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 @@
.. 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.
Modified: doctools/trunk/sphinx/style/default.css
==============================================================================
--- doctools/trunk/sphinx/style/default.css (original)
+++ doctools/trunk/sphinx/style/default.css Sun Aug 5 14:26:55 2007
@@ -638,6 +638,11 @@
content: ":";
}
+div.body p.centered {
+ text-align: center;
+ margin-top: 25px;
+}
+
table.docutils {
border: 0;
}
Modified: doctools/trunk/sphinx/style/traditional.css
==============================================================================
--- doctools/trunk/sphinx/style/traditional.css (original)
+++ doctools/trunk/sphinx/style/traditional.css Sun Aug 5 14:26:55 2007
@@ -547,6 +547,11 @@
content: ":";
}
+div.body p.centered {
+ text-align: center;
+ margin-top: 25px;
+}
+
table.docutils {
border: 0;
}
Modified: doctools/trunk/sphinx/writer.py
==============================================================================
--- doctools/trunk/sphinx/writer.py (original)
+++ doctools/trunk/sphinx/writer.py Sun Aug 5 14:26:55 2007
@@ -174,9 +174,9 @@
pass
def visit_centered(self, node):
- self.body.append(self.starttag(node, 'center') + '<strong>')
+ self.body.append(self.starttag(node, 'p', CLASS="centered") + '<strong>')
def depart_centered(self, node):
- self.body.append('</strong></center>')
+ self.body.append('</strong></p>')
def visit_compact_paragraph(self, node):
pass
More information about the Python-checkins
mailing list