Age | Commit message (Collapse) | Author | Files | Lines |
|
This reverts commit 2142bbe572cea00b7bb5ad3e10a3afb26845a1f7.
|
|
Try fixing a parsing error on windows by insisting that the parser use
a Posix filepath library for splitting doc paths in a zipfile. (It
might default on Windows to using a backslash as a separator, while
it's always a forward-slash in zip archives.)
|
|
* clarify function name. We had previously used `getDocumentPath`,
but `Document` is an overdetermined term here. Use
`getDocumentXmlPath` to make clear what we're doing.
* Use field notation for setting ReaderEnv. As we've added (and
continue to add) fields, the assignment by position has gotten
harder to read.
* figure out document.xml path once at the beginning of parsing, and
add it to the environment, so we can avoid repeated lookups.
|
|
Getting the location used to depend on a hard-coded .rels file based
on "word/document.xml". We now dynamically detect that file based on
the document.xml file specified in "_rels/.rels"
|
|
The desktop Word program places the main document file in
"word/document.xml", but the online word places it in
"word/document2.xml". This file path is actually stated in the root
"_rels/.rels" file, in the "Relationship" element with an
"http://../officedocument" type.
Closes #5277
|
|
For some reason, Word in Office 365 Online uses `document2.xml`
for the content, instead of `document.xml`. This causes pandoc
not to be able to parse docx.
This quick fix has the parser check for both `document.xml`
and `document2.xml`.
Addresses #5277, but a more robust solution would be to
get the name of the main document dynamically (who knows
whether it might change again?).
|
|
Quite a few modules were missing copyright notices.
This commit adds copyright notices everywhere via haddock module
headers. The old license boilerplate comment is redundant with this and has
been removed.
Update copyright years to 2019.
Closes #4592.
|
|
|
|
|
|
Otherwise last block gets parsed as a Plain rather than
a Para.
This is a regression in pandoc 2.x. This patch restores
pandoc 1.19 behavior.
Closes #5271.
|
|
Previously we didn't strip off the attachment: prefix,
so even though the attachment is available in the mediabag,
pandoc couldn't find it.
|
|
See #4213.
|
|
Add comment to remove it in next major release.
|
|
Now, instead of always creating temp dirs in the home
directory on Windows, we only do it if the system tempdir
name contains tildes. (This will be the case for longer
usernames only.)
Closes #1192.
|
|
Previously the temp directory was created inside the working
directory, so that programs like epstopdf.pl would be allowed
to run in restricted mode. However, setting TEXMFOUTPUT allows
these programs to run in the tmpdir inside the system temp
directory.
This is a better solution than cd51983. Using the system
temp dir prevents problems when pandoc is run inside a synced
directory (e.g. dropbox).
Partially addresses #1192.
|
|
fixes #5267
|
|
This is more elegant than the explicit recursive
we were using.
|
|
|
|
When `native_divs` and `markdown_in_html_blocks` are disabled
but `raw_html` and `markdown_attribute` are enabled...
|
|
`\ldots{}.` doesn't behave as well as `\ldots.` with the latex
ellipsis package. This patch causes pandoc to avoid emitting
the `{}` when it is not necessary. Now `\ldots` and other
control sequences used in escaping will be followed by either
a `{}`, a space, or nothing, depending on context.
Thanks to Elliott Slaughter for the suggestion.
|
|
`braced` now actually requires nested braces.
Otherwise some legitimate command and environment
definitions can break (see test/command/tex-group.md).
|
|
|
|
|
|
|
|
|
|
|
|
* docx writer: support custom properties. Solves the writer part of #3024.
Also supports additional core properties: `subject`, `lang`, `category`,
`description`.
* odt writer: improve standard properties, including the following core properties:
`generator` (Pandoc/VERSION), `description`, `subject`, `keywords`,
`initial-creator` (from authors), `creation-date` (actual creation date).
Also fix date.
* pptx writer: support custom properties. Also supports additional core
properties: `subject`, `category`, `description`.
* Includes golden tests.
* MANUAL: document metadata support for docx, odt, pptx writers
|
|
When pandoc is compiled with ghc 8.6, Windows paths are treated
differently, and paths beginning `\\server` no longer work.
This commit rewrites such patsh to `\\?\UNC\server` which works.
The change operates at the level of argument parsing, so it
only affects the command line program.
See #5127 and the discussion there.
|
|
Previously we were overwriting an existing identifier
with a new one. Closes #4731.
|
|
Partially addresses #4731.
We may not still be exactly matching mediawiki's algorithm
for identifiers.
|
|
This character needs special handling in lstinline.
Closes #4939.
|
|
|
|
This reverts commit 5eaff399d5d6dc30b0d453eff42c4101674d75ab.
|
|
`--include-in-header`, `--include-before-body`, `--include-after-body`
|
|
Closes #5251.
|
|
This avoids conflics with things like 'toc'.
|
|
|
|
[API change]
* Depend on ipynb library.
* Add `ipynb` as input and output format.
* Added Text.Pandoc.Readers.Ipynb (supports both nbformat v3 and v4).
* Added Text.Pandoc.Writers.Ipynb (supports nbformat v4).
* Added ipynb readers and writers to T.P.Readers,
T.P.Writers, and T.P.Extensions. Register the
file extension .ipynb for this format.
* Add `PandocIpynbDecodingError` constructor to Text.Pandoc.Error.Error.
* Note: there is no template for ipynb.
|
|
|
|
|
|
We don't want to parse its contents as Markdown or HTML.
Closes #5241.
|
|
Previously the `.0` was interpreted as a file extension,
leading pandoc not to add `.tex` (and thus not to find the
file).
The new behavior matches tex more closely.
|
|
|
|
fixes #2839
|
|
See pandoc/lua-filters#40.
|
|
|
|
Directives of this type without numeric inputs should not have a
`startFrom` attribute; with a blank value, the writers can produce
extra whitespace.
|
|
Closes #5208.
|
|
|
|
* These were added by the RST reader and, for literate Haskell,
by the Markdown and LaTeX readers. There is no point to
this class, and it is not applied consistently by all readers.
See #5047.
* Reverse order of `literate` and `haskell` classes on code blocks
when parsing literate Haskell. Better if `haskell` comes first.
|