| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| |
| |
| |
| |
| | |
mpickering-newbranch
Conflicts:
src/Text/Pandoc/Readers/EPUB.hs
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
| |
pandoc -t markdown-raw_html should not emit any raw HTML, even
span and div tags that go with pandoc Span and Div elements.
Cleaned up a bit of the logic with extensions and plain.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Renamed epub test files so they're identified more clearly as
epub: features.{epub,native} -> epub.features.{epub,native},
and similarly with formatting.{epub,native}.
Added epub test files to cabal file, so they'll be included in
the tarball.
|
| |
|
|
|
|
|
| |
This actually does what d71b013841f3c9c8c595591e312a31df16a728cb
said it did.
Revised epub tests to remove the repeated DOCTYPE and xml tags.
|
| |\
| |
| | |
EPUB Reader: Improved image extraction
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
mpickering-epubend
Conflicts:
pandoc.cabal
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Using `map toUpper` to capitalise text is wrong, as e.g.
“Straße” should be converted to “STRASSE”, which is 1 character
longer. This commit adds a `capitalize` function and replaces
2 identical implementations in different modules (`toCaps` and
`capitalize`) with it.
|
| |\ \ |
|
| | |/ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
This will allow us to test the whole mediabag (making sure, for example,
that images are added with the correct keys) instead of just individual
extracted images. We compare each entry in the media bag to an image
extracted on the fly from the docx. As a result, we only need one file
to test with.
The image in the current tests was also replaced with a smaller one.
|
| |
|
|
|
|
|
| |
Moved `MediaBag` definition and functions from Shared:
`lookupMedia`, `mediaDirectory`, `insertMedia`, `extractMediaBag`.
Removed `emptyMediaBag`; use `mempty` instead, since `MediaBag`
is a Monoid.
|
| |
|
|
|
|
|
|
|
|
| |
Shared now exports functions for interacting with a MediaBag:
- `emptyMediaBag`
- `lookuMedia`
- `insertMedia`
- `mediaDirectory`
- `extractMediaBag`
|
| | |
|
| |
|
|
| |
This is the cow image extracted from `docx.image.docx`.
|
| |
|
|
|
| |
Also tell pandoc.cabal that we'll be needing base64, since we want to
compare strings here.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1464.
|
| |\
| |
| | |
Make metadata out of styled pars
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will make paragraphs styled with `Author`, `Title`, `Subtitle`,
`Date`, and `Abstract` into pandoc metavalues, rather than text. The
implementation only takes those elements from the beginning of the
document (ignoring empty paragraphs).
Multiple paragraphs in the `Author` style will be made into a metaList,
one paragraph per item. Hard linebreaks (shift-return) in the paragraph
will be maintained, and can be used for institution, email, etc.
|
| |/
|
|
|
|
|
|
|
| |
Math now appears in unicode if possible, without the distracting
italics around identifiers.
Blank lines around headers are more consistent.
Footnotes appear in regular [n] style.
|
| | |
|
| |
|
|
| |
Closes #1452. Added test.
|
| |
|
|
|
| |
Of course, we can't include structure in the code block, but
this way we at least preserve the text. Closes #1449.
|
| |
|
|
| |
Closes #1434.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* This change brings pandoc's definition list syntax into alignment
with that used in PHP markdown extra and multimarkdown (with the
exception that pandoc is more flexible about the definition markers,
allowing tildes as well as colons).
* Lazily wrapped definitions are now allowed; blank space is required
between list items; and the space before definition is used to
determine whether it is a paragraph or a "plain" element.
* For backwards compatibility, a new extension,
`compact_definition_lists`, has been added that restores the behavior
of pandoc 1.12.x, allowing tight definition lists with no blank space
between items, and disallowing lazy wrapping.
|
| |
|
|
|
|
|
|
| |
This gives better results for tight lists. Closes #1437.
An alternative solution would be to use Para everywhere, and
never Plain. I am not sufficiently familiar with org to know
which is best. Thoughts, @tarleb?
|
| |
|
|
| |
Closes #1441.
|
| |
|
|
|
|
|
| |
Adds support to the org reader for conditionally exporting either the code block,
results block immediately following, both, or neither, depending on the value
of the `:exports` header argument. If no such argument is supplied, the default
org behavior (for most languages) of exporting code is used.
|
| |\
| |
| | |
Fix auto identified headers when already auto-id'ed
|
| | |
| |
| |
| | |
Test auto ident header anchors with pandoc-generated pandoc.
|
| |/
|
|
|
|
| |
This allows them to be styled using `\urlstyle{tt}`.
Thanks to Ulrike Fischer for the solution.
|
| |
|
|
|
|
| |
As far as I can see, dokuwiki markup is pretty limited in what
can go in a `>` block quote: just a single line of paragraph
text. (#1398)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
as in the mediawiki writer. The dokuwiki markup isn't able
to handle multiple block-level items within a list item, except
in a few special cases (e.g. code blocks, and these must be started
on the same line as the preceding paragraph). So we fall back to
raw HTML for these.
Perhaps there is a better solution. We can "fake" multiple
paragraphs within list items using hard line breaks (`\\`), but
we must keep everything on one line.
(#1398)
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Use removeFormatting from Shared instead of the custom unfancy
function.
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
The standard seems to be captions above tables. (See
http://tex.stackexchange.com/questions/3243/why-should-a-table-caption-be-placed-above-the-table)
|
| | |
|
| | |
|
