This uses the same macro for suppressing column colours which was used
for multi-column. Bottom cells of multi-row must have no colour panels,
else they hide the text which is inserted from the top row.
Indeed the ``l`` specifier must be avoided as much as possible to allow
cells having much more contents than others to be handled sanely.
Related to issue #3447. Parent commit would have made the issue more
frequent, this one helps restrain cases to those already in existence.
- allow multi-paragraph contents in grid table merged cells
- allow code-blocks in merged cells
- allow generally speaking reST contents allowed in regular
cells to be also allowed in merged cells, whether multirow,
multicolumn, or both.
This is made possible by custom LaTeX macros replacing original
``\multicolumn`` and ``\multirow`` (none of the originals allows
verbatim contents as is needed for code-blocks). They are defined in
bundled LaTeX style file sphinxmulticell.sty. The multicolumn merged
cells give much better results with tabulary as it is coerced into
taking them into account in its automatic width algorithm.
This deprecates use of LaTeX packages eqparbox and multirow, which are
not needed anymore.
New config setting ``latex_use_latex_multicolumn`` (default value False,
currently) as custom Sphinx multicolumn is not fully compatible will all
types of custom table col specs which may be inserted via tabularcolumns
directive. It works best with standard ``|`` column separator.
The default tabulary column specifier has been changed from L
(flushleft) to J (justifying). Internally the column type is called T,
so ``r'\newcolumntype{T}{L}'`` in preamble key recovers the former
behaviour. A ``\Y`` column type is defined which admits one decimal
argument in place of the two integers for ``\X``.
Like the recently added 'docs' target, this is easier than creating a
virtualenv, installing deps and running make.
Signed-off-by: Stephen Finucane <stephen@that.guru>
At present, the 'builder' option for the setuptools integration only
supports a single output format, typically HTML, like so:
[build_sphinx]
builder = man
There is value in being able to specify multiple format, like so:
[build_sphinx]
builder = html man
Make this possible.
Signed-off-by: Stephen Finucane <stephen@that.guru>
table directives on docutils-0.13.1+ set source information to
caption node. So these patch will be not necessary in feature
version of docutils.
https://sourceforge.net/p/docutils/patches/137/
For PDF via LaTeX PR #2304 (ac7d7b5) implemented wrapping of long code
lines in literal blocks and PR #3340 (8c21abe) extended this to parsed
literals. On this occasion the space was defined as a LaTeX macro,
depending on the used font, and as it allowed some potential uses it was
allowed for the space to obey the stretch and shrink as configured in
the used font. The default is to render using the mono font
(``\ttfamily``), hence a priori the stretchability and shrinkability are
anyhow zero. Non-zero stretch/shrink was left as a theoretical
possibility for special purposes; but although it may make sense to use
a "variable mono" for non-Python code, it is certainly not adequate for
things like verbatim grid tables...
The problem is that XeTeX does not set the TeX font parameters to zero
for OpenType fonts of Mono type, as is discussed there:
http://tug.org/pipermail/xetex/2017-January/026956.html
and in particular applies to the Latin Modern OpenType font, which is
the default when loading fontspec package. Due to this problem there was
a LaTeX kernel patch update late January 2017 to forcefully set the
corresponding TeX font parameters to zero (indeed since 2017/01/01
release LaTeX uses OpenType fonts by default under XeTeX/LuaTeX
engines.) But this is only a specific kludge for handling the Latin
Modern Mono font. Other OpenType fonts of MonoSpace type may still show
the XeTeX issue.
To make things simple, this commit simply avoids ascribing to the space
the font stretch or shrink as set in the TeX font parameters. This will
alleviate problems with Monospace fonts with XeTeX and avoir user
reports that their literal-blocks are all wrong.
Existing documents are not affected. The possibility to use a variable
space mono font had not been documented.
