Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
Closes #7374.
|
|
(commonmark_x, gfm). Closes #7375.
|
|
If inline references are used (in the metadata `references` field),
we should still only include in the bibliography items that are
actually cited -- unless `nocite` is used.
Closes #7376.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 61c0e0bbfbbaa53a31ba302237704001ca22e791.
|
|
|
|
|
|
Based on Doom Emacs's templates.
|
|
|
|
With the 2.14 release `--extract-media` stopped working as before;
there could be mismatches between the paths in the rendered document and
the extracted media.
This patch makes several changes (while keeping the same API).
The `mediaPath` in 2.14 was always constructed from the SHA1 hash of
the media contents. Now, we preserve the original path unless it's
an absolute path or contains `..` segments (in that case we use a path
based on the SHA1 hash of the contents).
When constructing a path from the SHA1 hash, we always use the
original extension, if there is one. Otherwise we look up an
appropriate extension for the mime type.
`mediaDirectory` and `mediaItems` now use the `mediaPath`, rather
than the mediabag key, for the first component of the tuple.
This makes more sense, I think, and fits with the documentation
of these functions; eventually, though, we should rework the API so that
`mediaItems` returns both the keys and the MediaItems.
Rewriting of source paths in `extractMedia` has been fixed.
`fillMediaBag` has been modified so that it doesn't modify
image paths (that was part of the problem in #7345).
We now do path normalization (e.g. `\` separators on Windows) only
in writing the media; the paths are left unchanged in the image
links (sensibly, since they might be URLs and not file paths).
These changes should restore the original behavior from before 2.14.
Closes #7345.
|
|
When we do a reverse lookup in the MIME table, we just get the
last match, so when the same mime type is associated with several
different extensions, we sometimes got weird results, e.g. `.vs`
for `text/plain`. These special cases help us get the most standard
extensions for mime types like `text/plain`.
|
|
A table header which does not contain any cells is now treated as an
empty header.
Fixes: #7369
|
|
Passing an empty list of header cells now results in an empty table
header.
Fixes: #7369
|
|
|
|
Fixed examples that would no longer compile with current library
versions, as the API now uses Text instead of String in most places.
|
|
This updates the manual and the web site about the GladTeX usage.
|
|
|
|
In recent versions the table headers were no longer bottom-aligned
(if more than one line). This patch fixes that by using minipages
for table headers in non-simple tables.
Closes #7347.
|
|
In https://github.com/jgm/pandoc/pull/7242, we introduced a simple attribute style for for code blocks and fenced divs with a single class but turns out the CommonMark extension does not support it for fenced divs.
https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/fenced_divs.md
|
|
Ext_attributes covers at least the following:
- Ext_fenced_code_attributes
- Ext_header_attributes
- Ext_inline_code_attributes
- Ext_link_attributes
|
|
Instead of duplicating linkAttributes and attrsToMarkdown, let’s just use those from the Inline module.
|
|
This fixes a bug which led to doubled "et al." in some
(rare) circumstances.
|
|
Added in DocBook 5.2:
- https://github.com/docbook/docbook/pull/64
- https://tdg.docbook.org/tdg/5.2/danger.html
|
|
attention, error and hint are actually just reStructuredText specific.
danger was too until introduced in DocBook 5.2: https://github.com/docbook/docbook/issues/55
|
|
This ensures that we get `\` separators on Windows.
|
|
|
|
|
|
Closes #7344.
|
|
Closes #7342.
|
|
Previously pipe tables with empty headers (that is, a header
line with all empty cells) would be rendered as headerless
tables. This broke in 2.11.4.
The fix here is to produce an AST with an empty table head
when a pipe table has all empty header cells.
Closes #7343.
|
|
Generally we allow optional starred variants of LaTeX commands
(since many allow them, and if we don't accept these explicitly,
ignoring the star usually gives acceptable results). But we
don't want to do this for `\(*\)` and similar cases.
Closes #7340.
|
|
This was actually part of the 2.14 release.
|
|
|
|
A regression in 2.14 led to the document body being omitted
after YAML metadata in some cases. This is now fixed.
Closes #7339.
|
|
|
|
Column widths specified with a style attribute were
off by a factor of 100 in 2.14.
Closes #7334.
|