| Age | Commit message (Collapse) | Author |
|---|
|
Each worksheet turns into a section containing a table.
The common file `nativeDiff` has been extract from
the Docx and Pptx text files and put in Tests.Helpers.
|
|
New module `Text.Pandoc.Readers.Pptx`,
exporting `readPptx`. [API change]
Factored out some common OOXML functions from
Text.Pandoc.Readers.Docx.Util into a non-exported module
Text.Pandoc.Readers.OOXML.Shared.
|
|
`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.
|
|
This adds a reader and writer for an XML format equivalent to `native`
and `json`.
XML schemas for validation can be found in `tools/pandoc-xml.*`.
The format is documented in `doc/xml.md`.
API changes:
- Add module Text.Pandoc.Readers.XML, exporting `readXML`.
- Add module Text.Pandoc.Writers.XML, exporting `writeXML`.
A new unexported module Text.Pandoc.XMLFormat is also added.
|
|
|
|
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
|
|
This change introduces a reader for mdoc, a roff-derived semantic markup
language for manual pages. The two relevant contemporary implementations
of mdoc for manual pages are mandoc (https://mandoc.bsd.lv/), which
implements the language from scratch in C, and groff
(https://www.gnu.org/software/groff/), which implements it as roff macros.
mdoc has a lot of semantics specific to technical manuals that aren't
representable in Pandoc's AST. I've taken a cue from the mandoc HTML
output and many mdoc elements are encoded as Codes or Spans with classes
named for the mdoc macro that produced them.
Much like web browsers with HTML, mandoc attempts to produce best-effort
output given all kinds of weird and crappy mdoc input. Part of the
reason it's able to do this is it uses a very accommodating parse tree
and stateful output routines specialized to the output mode, and when it
encounters some macro it wasn't expecting, it can easily give up on
whatever it was outputting and output something else. I've encoded as
much flexibility as I reasonably could into the mdoc reader here, but I
don't know how to be as flexible as mandoc.
This branch has been developed almost exclusively against mandoc's
documentation and implementation of mdoc as a reference, and the
real-world manual pages tested against are those from the OpenBSD base
system. Of ~3500 manuals in mdoc format shipped with a fresh OpenBSD
install, 17 cause the mdoc reader to exit with a parse error. Any
further chasing of edge cases is deferred to future work.
Many of the tests in test/Tests/Readers/Mdoc.hs are derived directly
from mandoc's extensive regression tests.
[API change] Adds readMdoc to the public API
|
|
|
|
They now return `Either OptInfo Opt`.
Add `OptInfo` type.
Add `handleOptInfo` function. This performs the IO actions for
things like `--version` that were previously done in `parseOptionsFromArgs`.
An argument for a `ScriptingEngine` has been added, to facilitate
printing custom templates and custom extensions for Lua filters.
(However, at this stage nothing is yet done with it.)
[API change]
|
|
For consistency with Writers.ODT.
Similarly, rename `readOdt` -> `readODT`.
[API change]
|
|
Similarly, rename `writeDocbook` -> `writeDocBook`, for
consistency with the DocBook reader's naming.
[API change]
|
|
Rolls back 0ab014ed1e5890e338792fab98aecc45cd889f99.
We don't need this because we aren't needing to print the Lua
version in options any more; we're handling `--version` now at
the pandoc-cli level.
|
|
The flag 'lua53` must now be used with that package if pandoc is to be
compiled against Lua 5.3.
|
|
|
|
|
|
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.
|
|
- `rtf` is now supported as an input format as well as output.
- New module Text.Pandoc.Readers.RTF (exporting `readRTF`). [API change]
Closes #3982.
|
|
avoiding the need to depend on the executable-path package.
|
|
|
|
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.
|
|
Writers.Tables is now Writers.AnnotatedTable. All of the types and
functions in it have had the "Ann" removed from them. Now it is
expected that the module be imported qualified.
|
|
Add Writers.Tables helper functions and types, add tests for those
The Writers.Tables module contains an AnnTable type that is a pandoc
Table with added inferred information that should be enough for
writers (in particular the HTML writer) to operate on without having
to lay out the table themselves.
The toAnnTable and fromAnnTable functions in that module convert
between AnnTable and Table. In addition to producing an AnnTable with
coherent and well-formed annotations, the toAnnTable function also
normalizes its input Table like the table builder does.
Various tests ensure that toAnnTable normalizes tables exactly like
the table builder, and that its annotations are coherent.
|
|
If a line of ms code block output starts with a period (.), it should
be prepended by '\&' so that it is not interpreted as a roff command.
Fixes #6505
|
|
- Writers.Native is now adapted to the new Table type.
- Inline captions should now be conditionally wrapped in a Plain, not
a Para block.
- The toLegacyTable function now lives in Writers.Shared.
|
|
Spans with class `underline` as converted into Jira text marked as
`+inserted+`, i.e. surrounded by plus-signs.
|
|
Closes #5556
|
|
This makes use of tasty-lua, a package to write tests in Lua
and integrate the results into Tasty output. Test output becomes
more informative: individual tests and test groups become visible
in test output. Failures are reported with helpful error messages.
|
|
|
|
Closes #1792
|
|
|
|
|
|
|
|
|
|
This seems to be necessary if we are to use our custom Prelude
with ghci.
Closes #4464.
|
|
|
|
This is the beginning of a test suite for the powerpoint
writer. Initial tests are for the number of slides.
Note that at the moment it does not test against corruption in
Microsoft PowerPoint; it just tests that certain outcomes work as
expected. More tests will be added.
This test framework uses the PandocPure monad introduced with Pandoc 2.0.
|
|
|
|
Support writing <fig> and <table-wrap> elements with <title> and
<caption> inside them by using Divs with class set to on of
fig, table-wrap or cation. The title is included as a Heading
so the constraint on where Heading can occur is also relaxed.
Also leaves out empty alt attributes on links.
|
|
|
|
|
|
This is feature complete but not very thoroughly tested yet.
|
|
|
|
* Add `--lua-filter` option. This works like `--filter` but takes pathnames of special lua filters and uses the lua interpreter baked into pandoc, so that no external interpreter is needed. Note that lua filters are all applied after regular filters, regardless of their position on the command line.
* Add Text.Pandoc.Lua, exporting `runLuaFilter`. Add `pandoc.lua` to data files.
* Add private module Text.Pandoc.Lua.PandocModule to supply the default lua module.
* Add Tests.Lua to tests.
* Add data/pandoc.lua, the lua module pandoc imports when processing its lua filters.
* Document in MANUAL.txt.
|
|
|
|
* Add Muse writer
* Advertise new Muse writer
* Muse writer: add regressions tests
|
|
|
|
|
|
Any files added under test/command will be treated as
shell tests (see smart.md for an example).
This makes it very easy to add regression tests etc.
|
|
|
|
|
