The removal of an `\everyeof{}` from `\sphinxcode` was causing
never-ending loop if the latter expanded inside `\sphinxhref`. The bug
was introduced at 3128a43, it thus never made it to a release yet.
Catching it in time for 1.5.4.
Although the data in ``\pdfinfo`` as set-up in ``sphinxmanual.cls`` was
ignored, some LaTeX commands (e.g. ``\large``) in the ``latex_documents``
title item could cause failed PDF builds.
This commit removes the anyhow ignored ``\pdfinfo`` usage, and indicates
in commented-out lines how to use ``\hypersetup``, which may be done in
master branch, or possibly in stable branch, if some consensus emerges
about how to represent ``\and`` in the ``/Author`` field. It seems the
PDF Document Information Dictionary does not seem to provide any
universal multi-lingual way to indicate multiple authors.
Probably for accidental reasons, pdflatex and lualatex (but not platex
and xelatex) were configured with a blank line above the logo on title
page, below the top rule. This commit removes it.
The file ``pdfcolor.tex`` included in tex distributions is for Plain
pdfTeX, not for LaTeX use. Loading it complicates task of supporting
multiple TeX engines. If needed all corresponding colour names are
better available from passing to ``color`` or ``xcolor`` the
``dvipsnames`` option. It is better to leave responsability of using
this option to Sphinx user, if needed. The macros for setting the color
defined by ``pdfcolor.tex`` were never documented to Sphinx user, and
they can not be used from reST apart from ``.. raw:: latex`` directive,
they are for Plain TeX without use of ``color`` package. Thus, this
commit drops loading this file and the complicated conditionals around
it (``\ifsphinxpdfoutput``), which are also used in the class files
``sphinxmanual.cls``, ``sphinxhowto.cls``.
Also, this fixes issue #2693.
This reverts commit 7db8141238.
As discussed at
<https://github.com/sphinx-doc/sphinx/pull/2736#issuecomment-230140016>
platex and xelatex engines led to a slightly different title page layout
missing a blank line underneath the top rule (above the logo) compared
to pdflatex and lualatex. This was probably accidental.
All LaTeX commands such as \textbf, \emph, \underline.. are "short",
thus there was no need of ``\long`` prefix. Regarding
``\sphinxoptional`` which was defined via ``\newcommand``, the ``\long``
is there for full backwards compatibility, but a priori the argument
will always be a "short" one (i.e. not containing empty line or ``\par``
token.)
Since #3022 (Sphinx 1.5) more footnotes are hyperlinked but it became
impossible for Sphinx user to pass option ``hyperfootnotes=false`` to
package ``hyperref``. Release 1.0 of LaTeX package ``footnotehyper``,
which serves as bugfix replacement to older package ``footnote``, is
compatible with ``hyperfootnotes=false``, hence it is again possible to
Sphinx user to completely disable hyperlinking of footnotes, if ever
needed.
in particular:
``\sphinxbelowtablecaptionskip`` renamed to ``\sphinxbelowcaptionskip``
as it may be extended in future to usage for captions of literal blocks.
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``.
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.
Jean-François B