Henceforth pandoc-cli's version will be synchronized with pandoc's, and
pandoc-cli will depend on an exact pandoc version.
This will avoid confusion by ensuring that `cabal install pandoc-cli-X.Y.Z`
installs pandoc version X.Y.Z. It will make things more straightforward
for upstream packagers (see #9232).
Note also that the man pages included in this package are for a specific
pandoc version.
This scheme does not follow the Haskell PVP, but that should cause no
harm, because this package does not expose a library.
* To conform to validator's expectations, `doc-footnote` role is used
with `aside` and `doc-endnotes` with `section`.
* `aside` is used only for notes at ends of sections or blocks;
if all the notes come at the end of the document, `section` is
used so we can have the `doc-endnotes` role.
Add T.P.Readers.Docx.Symbols. This gives us a table to use to
resolve characters included in docx via w:sym element.
Use this table to resolve characters when symbol fonts are specified.
Closes#9220.
- Ensure unique ids for elements by prefixing SVG id.
- Ensure SVG `id` attribute except when `use` element is used.
- Remove `width`, `height` attributes from svg element when `use`
element is used. Instead, add `width` and `height` 100% to the
`use` element. This seems to get the sizing right.
Closes#9206.
Ref: #8948.
Closes#8872.
In the current implementation , theorem labels in `theoremEnvironment` are
determined by the `LastLabel` in the current state.
This approach works well when the `\label{label_name}` is placed at the end
of the theorem body. However, when a label is placed at the beginning of the
theorem (another common practice) and additional labels follow in the theorem body,
`theoremEnvironment` incorrectly picks the last label (e.g., `\label{item2}` in #8872).
This patch addresses the issue by extracting the label extraction independently of the `LastLabel` state.
- Only treat as base64 if ';base64' is present.
- Otherwise treat as UTF-8 (not 100% reliable but should cover most
other cases).
- Strip off ';base64' (or ';charset=...' or whatever) from mime type.
This last change addresses #9195 (problems with data URIs in
conversion to docx).
This revises the fix to #8150 (and the test case) and closes#9187.
HTML in the (invalid) form:
<ul>
<li>L1</li>
<ul>
<li>L1.1</li>
</ul>
</ul>
is treated by browsers like
<ul>
<li>L1
<ul>
<li>L1.1</li>
</ul>
</li>
</ul>
not
<ul>
<li>L1
<li><ul>
<li>L1.1</li>
</ul>
</li>
</ul>
as pandoc previously assumed.
This change will give a similar treatment to
<ul>
<li>L1</li>
<p>foobar</p>
</ul>
which also seems to match browser behavior.
John MacFarlane