Docbook, EPUB, FB2, HTML4, S5, Slidy, Slideous,
ICML, ODT, TEI writers.
Thus, if you convert `[anchor]{#1} and [link to](#1)`,
`id_1` will be used instead of `1` for the identifier.
This function changes identifiers that don't start
with letters, and internal links to these identifiers,
making them compatible with XML standards. The change
is simple: we add `id_` to the front. There is potential
for duplication if there are already `id_...` identifiers
defined, but this seems rare enough not to worry too much
about.
If scrreport is now chosen as the latex documentclass chapters will be used instead of sections. This behaviour is intended as scrreport is an alias for scrreprt which already created chapters
Looking at the definition of `org-element-latex-environment-parser`, one
sees that Org allows arbitrary arguments to LaTeX environments. In fact,
it parses every char just after `\begin{xxx}` until `\end{xxx}` as
content for the environment, so all the following examples are valid
environments:
```org
\begin{equation} e = mc^2 \end{equations}
```
```org
\begin{tikzcd}[ampersand replacement=\&]
A \& B \\
C \& D
\arrow[from=1-1, to=1-2]
\arrow["f", from=2-1, to=2-2]
\end{tikzcd}
```
Lua 5.4 is used by default after this is merged. Packagers may still include Lua 5.3
instead by building pandoc with `--constraint='hslua <2.2'`.
Differences between 5.3 and 5.4 should not generally affect pandoc Lua filters.
See list of incompatible changes here <https://www.lua.org/manual/5.4/manual.html#8.1>
Previously we used the markdown writer to render metadata.
This had some undesirable consequences (e.g. en dash expanded
to `--` when `smart` enabled), so now we use the plain writer.
This addresses #7928, but I think a more elegant fix is possible.
...so that, when the input format is not markdown or a markdown
variant, pandoc's markdown is used. When the input format is
a markdown variant, the same format is used. Reason for the change:
it doesn't make sense to run the markdown parser with a set of
extensions designed for a non-markdown format, and this dramatically
limits what people can do in metadata files.
Refines #6832. Closes#7926.
Perhaps this can be reconsidered if we come up with a way
of specifying an arbitrary format for the metadata file (#5914).
Footnotes in `<fn-group>` elements are collected and re-inserted into
the document as proper footnotes in the place where they are referenced.
Fixes: #6348
Closes#5202.
Within each cell, determine the cell alignment as per
https://www.dokuwiki.org/wiki:syntax#tables. The current approach, as
per the issue treats the first row's alignment as determining
that of the entire column. Given this, it wastes some work in
determining an alignment for every cell.
This change ensures that example list items all belong to a single
number sequence, so that if items are added or deleted in a word
processor, the other items will renumber automatically.
when parsing `<a epub:type="noteref">` and the identifier
doesn't correspond to anything in the note table.
Previously we just silently skipped these cases.
See #7884.
The Org Manual page at https://orgmode.org/manual/Property-Syntax.html
says (as of 2022-02-03):
"Property blocks defined before first headline needs to be located at
the top of the buffer, allowing only comments above."
This commit allows comments above.
Any non-space character is allowed as property drawer key, including ":"
itself (so it is not really a delimiter). The real delimiter is a space
character, so in a drawer like
:PROPERTIES:
::k:ey:: value
:END:
":k:ey:" is a key with value "value".
This usage can be seen in the Org Manual at
https://orgmode.org/manual/Using-Header-Arguments.html,
where the Org snippet
* Heading
:PROPERTIES:
:header-args:clojure: :session *clojure-1*
:header-args:R: :session *R*
:END:
is listed as an example.
Links without text contents are converted to `<xref>` elements. DocBook
processors will generate appropriate cross-reference text when presented
with an xref element.
