This replaces (now deprecated but still functional) options
`--mathml`, `--mathjax`, `--gladtex`, `--katex`, `--webtex`.
The `plain` style can now be specified explicitly.
In defaults files, `html-math-method` is now
`math-method` (though `html-math-method` will still work).
Text.Pandoc.App.Opt:
- In unexported type CompletionKind, add MathMethods.
- In Opt, change `optHTMLMathMethod` to `optMathMethod`. [API change]
Text.Pandoc.Options:
- Rename HTMLMathMethod type to MathMethod. [API change]
- Rename `writerHTMLMathMethod` field of WriterOptions to
`writerMathMethod`. [API change]
Text.Pandoc.App.Completion:
- Clean up code.
- Add support for `--math-method`.
`t2t` is now supported as an output format, producing Txt2Tags
markup (<https://txt2tags.org>). The writer covers headers, lists
(bullet, ordered, definition), tables, links, images, code blocks,
inline formatting, and raw txt2tags/HTML passthrough.
[API change]
Adds a new module Text.Pandoc.Writers.Txt2Tags, exporting
`writeTxt2Tags`. Also exported from Text.Pandoc.Writers.
Co-authored-by: luginf <alan@luginf>
New exported module Text.Pandoc.Readers.AsciiDoc,
exporting readAsciiDoc [API change].
The bulk of parsing is handled by the asciidoc library.
Closes#1456.
`bbcode` is now supported as an output format, as well as variants
`bbcode_fluxbb` (FluxBB), `bbcode_phpbb` (phpBB), `bbcode_steam` (Hubzilla),
`bbcode_hubzilla` (Hubzilla), and `bbcode_xenforo` (xenForo).
[API change]
Adds a new module Text.Pandoc.Writers.BBCode, exporting a number of functions.
Also exports `writeBBCode`, `writeBBCodeSteam`, `writeBBCodeFluxBB`,
`writeBBCodePhpBB`, `writeBBCodeHubzilla`, `writeBBCodeXenforo` from
Text.Pandoc.Writers.
Support for vimdoc, documentation format used by vim in its help pages.
Relies heavily on definition lists and precise text alignment to generate tags.
...to determine what to do about `.pdfhref` macros in `ms`
output.
When no PDF engine is specified, we don't use the `.pdfhref`
macros at all. This gives better results for links in formats
other than PDF, since the link text would simply disappear if
it exists only in a `.pdfhref` macro.
When a PDF engine is specified, escape the argument of
`.pdfhref O` in a way that is appropriate.
Remove `groff` extension.
Text.Pandoc.Extensions: remove `Ext_groff` constructor.
See #10738. This revises the earlier commit
3adcb4bd80.
Pod ("Plain old documentation") is a markup languaged used principally
to document Perl modules and programs. Since it was originally meant to
be translated pretty directly to man, the semantics are fairly simple.
This Pod reader was developed with reference to the canonical user and
implementer documentation of Pod: https://perldoc.perl.org/perlpod and
https://perldoc.perl.org/perlpodspec.
There are 1490 .pod, .pl, and .pm in the Perl 5.34 distribution found in
/System/Library/Perl on my mac. Of those, this reader dies with a parse
error on 7 of them. All of them seem to be cases where pod commands are
found within a non-colon-prefixed =begin/=end. perlpodspec says I may
treat this as an error.
[API change] adds readPod
* Typst writer: support Typst 0.11 table features.
- colspans
- rowspans
- cell alignment overrides
- relative column widths
- header and footer
- multiple table bodies with intermediate headers
Row heads are not yet supported.
The default typst template has been modified so that tables
don't have lines by default. As is standard with pandoc, we only
add a line under a header or over a footer. However, a different
default stroke pattern can easily be added in a template.
Closes#9588.
Djot is a light markup syntax (https://djot.net).
This patch adds djot as input and output formats.
API changes:
Add Text.Pandoc.Readers.Djot
Add Text.Pandoc.Writers.Djot
The AsciiDoc community now regards the dialect parsed by `asciidoctor`
as the official AsciiDoc syntax, so it should be the target of our
`asciidoc` format.
Closes#8936.
The `asciidoc` output format now behaves like `asciidoctor` used to.
`asciidoctor` is a deprecated synonynm. For the old `asciidoc` behavior
(targeting the Python script), use `asciidoc_legacy`.
The templates have been consolidated. Instead of separate
`default.asciidoctor` and `default.asciidoc` templates, there is
just `default.asciidoc`.
Text.Pandoc.Writers.AsciiDoc API changes:
- `writeAsciiDoc` now behaves like `writeAsciiDoctor` used to.
- `writeAsciiDoctor` is now a deprecated synonym for `writeAsciiDoc`.
- New exported function `writeAsciiDocLegacy` behaves like
`writeAsciDoc` used to.
Markua is a markdown variant used by Leanpub.
More information about Markua can be found at https://leanpub.com/markua/read.
Adds a new exported function `writeMarkua` from T.P.Writers.Markdown.
[API change]
Closes#1871.
Co-authored by Tim Wisotzki and Samuel Lemmenmeier.
Previously, both `fmt == f` case and Image have a rank of 1.
In the end, e.g. from ipynb to html conversion,
if both html and image exists, it actually prefers the image.
This commit changes this, so that fmt == f is always highest rank,
and rank never collides.
This is achieved by keeping fmt == f case having rank 1,
and every other rank increased by 1.
Write RawBlock of markdown in code-cell output.
#7561 makes the ipynb reader reads code-cell output with mime
"text/markdown" to a RawBlock of markdown
This commit makes the ipynb writer writes this RawBlock of markdown
back inside a code-cell output with the same mime, preserving this
information in round-trip
Add tests of ipynb reader (#7561) and ipynb writer (#7563)'s ability to
handle a "text/markdown" mime type in a code-cell output
Previously we used our own homespun formatting. But this
produces over-long lines that aren't ideal for diffs in tests.
Easier to use something off-the-shelf and standard.
Closes#7580.
Performance is slower by about a factor of 10, but this isn't
really a problem because native isn't suitable as a serialization
format. (For serialization you should use json, because the reader
is so much faster than native.)
Apparently Cabal sets a `pandoc_datadir` environment variable
so that the data files will be sought in the source directory
rather than in the final destination (where they aren't yet
installed).
So we no longer need to set `--data-dir` in the tests. We just
need to make sure `pandoc_datadir` is set in the environment
when we call the program in the test suite.
This will fix the issue with loading of pandoc.lua when
pandoc is built with `-embed_data_files`, reported in #7163.
Closes#7163.
[API change] This affects `readFile`, `getContents`, `writeFileWith`,
`writeFile`, `putStrWith`, `putStr`, `putStrLnWith`, `putStrLn`.
`hPutStrWith`, `hPutStr`, `hPutStrLnWith`, `hPutStrLn`, `hGetContents`.
This avoids the need to uselessly create a linked list of characters
when emiting output.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
Note that the multirow package is needed for rowspans.
It is included in the latex template under a variable,
so that it won't be used unless needed for a table.
Previously we used Setext (underlined) headings by default.
The default is now ATX (`##` style).
* Add the `--markdown-headings=atx|setext` option.
* Deprecate `--atx-headers`.
* Add constructor 'ATXHeadingInLHS` constructor to `LogMessage` [API change].
* Support `markdown-headings` in defaults files.
* Document new options in MANUAL.
Closes#6662.
* Fix hlint suggestions, update hlint.yaml
Most suggestions were redundant brackets. Some required
LambdaCase.
The .hlint.yaml file had a small typo, and didn't ignore camelCase
suggestions in certain modules.
New formats:
- `jats_archiving` for the "Archiving and Interchange Tag Set",
- `jats_publishing` for the "Journal Publishing Tag Set", and
- `jats_articleauthoring` for the "Article Authoring Tag Set."
The "jats" output format is now an alias for "jats_archiving".
Closes: #6014
* Set dbBook to true when traversing a chapter too.
Currently, a `<title/>` in a chapter and in a `<section/>` below that
chapter have the same level if they're not inside a `<book/>`.
This can happen in a multi-file book project. Also see the example at
https://tdg.docbook.org/tdg/4.5/chapter.html
Co-authored-by: Félix Baylac-Jacqué <felix@alternativebit.fr>
* Add docbook-chapter test
This tests nested `<section/>` and makes sure `<title/>` in the first
`<section/>` below `<chapter/>` is one level deeper than the `<chapter/>`'s
`<title/>`, also when not inside a `<book/>`.
Co-authored-by: Félix Baylac-Jacqué <felix@alternativebit.fr>