Closes#5285. Previously the algorithm allowed list items
with a mix of Para and Plain, which is never wanted.
compactify in T.P.Shared has been modified so that, if
a list's items contain (at the top level) Para elements
(aside from perhaps at the very end), ALL Plains are
converted to Paras.
Quite a few modules were missing copyright notices.
This commit adds copyright notices everywhere via haddock module
headers. The old license boilerplate comment is redundant with this and has
been removed.
Update copyright years to 2019.
Closes#4592.
Otherwise last block gets parsed as a Plain rather than
a Para.
This is a regression in pandoc 2.x. This patch restores
pandoc 1.19 behavior.
Closes#5271.
`\ldots{}.` doesn't behave as well as `\ldots.` with the latex
ellipsis package. This patch causes pandoc to avoid emitting
the `{}` when it is not necessary. Now `\ldots` and other
control sequences used in escaping will be followed by either
a `{}`, a space, or nothing, depending on context.
Thanks to Elliott Slaughter for the suggestion.
* docx writer: support custom properties. Solves the writer part of #3024.
Also supports additional core properties: `subject`, `lang`, `category`,
`description`.
* odt writer: improve standard properties, including the following core properties:
`generator` (Pandoc/VERSION), `description`, `subject`, `keywords`,
`initial-creator` (from authors), `creation-date` (actual creation date).
Also fix date.
* pptx writer: support custom properties. Also supports additional core
properties: `subject`, `category`, `description`.
* Includes golden tests.
* MANUAL: document metadata support for docx, odt, pptx writers
Otherwise we get an error when trying to compile code
with lua or assembler code.
To change the default dialect (currenty 5.3 for lua
and x86masm for assembler), you can use `--include-in-header`
to inject something like
\lstset{defaultdialect=[5.2]Lua}
Closes#5227.
Ensure that `\part` and `\chapter` are only numbered if `numbersections` is set. To return to the previous behaviour, use `-V numbersections -V secnumdepth=0`.
Notes on secnumdepth:
1 = Number `\section`
0 = Number `\chapter`
-1 = Number `\part`
-2 = No numbering
Incorrect types to pandoc element constructors are automatically
converted to the correct types when possible. This was already done for
most constructors, but conversions are now also done for nested
types (like lists of lists).
Simplify the approach of #5212, ensuring that `mainfont` is used as the base font for scaling and that LuaLaTeX does not display the mono font with TeX ligatures (as it does not use the `Mapping=tex-ansi` option).
With a modified version of `\defaultfontfeatures`, fontspec will continue to report scaling against the old default font in the log, but it nonetheless displays main font at the specified size. Using this rather than setting `Scale=MatchLowercase` for each family individually means that users will not lose scaling when upgrading to the new template if they were using other font options. Scaling can be disabled for an individual family by adding the option `Scale=1` to `sansfontoptions`, `monofontoptions`, etc.
Remove the `\setromanfont` command added in #4665, as this is not documented in the fontspec manual and appears to be a deprecated alias for `\setmainfont`.
For the release notes, I should also add that one can imitate the previous appearance with `-V mainfontoptions="Scale=MatchLowercase"`.
When `Scale=MatchLowercase` is set as a default font option, this scales `mainfont` against the old default, meaning that it resizes whatever is set as the main font to match the metrics of Latin Modern. This can result, for example, in a document set to 12pt appearing in 11pt or 13pt. Setting this option for individual families allows everything to scale against the main font, and permits the user to override the setting if desired. Note that it is not necessary to specify `Ligatures=TeX`, as this is already set by default for the appropriate families. See the `fontspec` manual: <https://ctan.org/pkg/fontspec>.
Those who specify font-options in metadata may need to add `Scale=MatchLowercase`, which will now only be provided if `(roman|sans|math|mono)fontoptions` aren't given explicitly.
* These were added by the RST reader and, for literate Haskell,
by the Markdown and LaTeX readers. There is no point to
this class, and it is not applied consistently by all readers.
See #5047.
* Reverse order of `literate` and `haskell` classes on code blocks
when parsing literate Haskell. Better if `haskell` comes first.
* Use Babel for LuaTeX. There are a number of bugs in Polyglossia under LuaLaTeX with common languages, e.g. <https://github.com/reutenauer/polyglossia/issues/182>.
* Load xcolor. The `xcolor` package must be loaded before the `footnote` package, which we load to fix foonotes in tables. Closes#4861.
* Load xurl if available. This breaks URLs in more locations. Only available with TeX Live 2018 and later.
* Remove obsolete fixltx2e package
* Reindent. Use two spaces to be consistent internally and with other templates.
* Use `bookmark` if available. The `bookmark` package can sometimes correct the levels of headings where `hyperref` cannot: see <https://komascript.de/release3.26>.
* Update LaTeX tests
* FIX#5183 : zimwiki : remove automatic colon prefix before internal images
 should be converted to {{foo.png}} (relative path)
Therefore the ':' prefix is useless and must be removed.
I never used the zimwiki, but i submitted the similar dokuwiki fix.
1. The zimwiki syntax is inspired by dokuwiki
2. The zimwiki documentation does not mention the colon character for images
3. The pandoc zimwiki writer seems to be a copy-paste for the dokuwiki writer
If the PR #5184 is applied, I think this one should be applied too.
* FIX#5183 : remove automatic ':' prefix before internal image links
`` should be converted to `{{foo.png}}` (relative path)
`
Therefore the ':' prefix is useless and must be removed.
It blocks users from making relative image links.
Update tests for DokuWiki Writer : external images
Previously we used HsYAML's decodeStrict to recognize
boolean values (treating everything else as a string).
This caused problems relating to hvr/HsYAML#7.
We now just check for the recognized boolean values
`true|True|TRUE|false|False|FALSE`, and avoid using
HsYAML.
Closes#5177.
