Age | Commit message (Collapse) | Author | Files | Lines |
|
* New module `Text.Pandoc.Docx`.
* New output format `docx`.
* Added reference.docx.
* New option `--reference-docx`.
The writer includes support for highlighted code blocks
and math (which is converted from TeX to OMML using
texmath's new OMML module).
|
|
|
|
Top line of table must not be followed by a blank line.
This bug caused slowdown on some files with hrules and tables,
and pandoc tried to interpret the hrules as the tops of
multiline tables.
|
|
This change also means that
[link with [link](/url)](/url)
will turn into
<p><a href="/url">link with link</a></p>
instead of
<p><a href="/url">link with [link](/url)</a></p>
|
|
Pandoc previously behaved like Markdown.pl for consecutive
lists of different styles. Thus, the following would be parsed
as a single ordered list, rather than an ordered list followed
by an unordered list:
1. one
2. two
- one
- two
This patch makes pandoc behave more sensibly, parsing this as
two lists. Any change in list type (ordered/unordered) or in
list number style will trigger a new list. Thus, the following
will also be parsed as two lists:
1. one
2. two
a. one
b. two
Since we regard this as a bug in Markdown.pl, and not something
anyone would ever rely on, we do not preserve the old behavior
even when `--strict` is selected.
|
|
* `---` is always em-dash, `--` is always en-dash.
* pandoc no longer tries to guess when `-` should be en-dash.
* A new option, `--old-dashes`, is provided for legacy documents.
Rationale: The rules for en-dash are too complex and
language-dependent for a guesser to work reliably. This
change gives users greater control. The alternative of
using unicode isn't very good, since unicode em- and en-
dashes are barely distinguishable in a monospace font.
|
|
Inline math uses the :math:`...` construct.
Display math uses
.. math:: ...
or if multilin
.. math::
...
These seem to be supported now by rst2latex.py.
|
|
Inline: :math:`E=mc^2`
Block:
.. math: E = mc^2
.. math::
E = mc^2
a = b^2
(This latter will turn into a paragraph with two
display math elements.)
Closes #117.
|
|
* Added stateLastStrPos to ParserState. This lets us keep track
of whether we're parsing the position immediately after a 'str'.
If we encounter a ' in such a location, it must be an apostrophe,
and can't be a single quote start.
* Set this in the markdown, textile, html, and rst str parsers.
* Closes #360.
|
|
|
|
|
|
|
|
This solves a problem stemming from the fact that a parser
doesn't know what came *before* in the input stream.
Previously pandoc would parse
D'oh l'*aide*
as containing a single quoted "oh l", when both `'`s should
be apostrophes. (Issue #360.) There are two issues here.
(a) It is obvious that the first `'` is not an open quote,
becaues of the preceding `D`. This patch solves the problem.
(b) It is obvious to us that the second `'` is not an
open quote, because we see that *aide* is some text.
But getting a good algorithm that has good performance is
a bit tricky. You can't assume that `'` followed by `*`
is always an apostrophe:
*'this is quoted'*
This patch does not fix (b).
|
|
Closes #312.
|
|
|
|
|
|
Refactored escapedChar into escapedChar', escapedChar.
|
|
|
|
Closes #314.
|
|
Closes #322.
|
|
Previously `[@item1 and nowhere else]` yielded the locator ", and nowhere
else", or, with the new citeproc-hs, "and nowhere else".
Now it yields " and nowhere else".
|
|
Partially resolves issue #333.
|
|
The characters '.',':',';','$','<','>','~','#','-','_' can
be used only between two letters or digits in a citation key.
This means that '@item1.' will be parsed as a citation, 'item1',
followed by a period, instead of a citation 'item1.', as was the
case previously.
Thanks to David Sanson for alerting us to the problem.
|
|
It was always possible to include raw DocBook tags in a markdown
document, but now pandoc will be able to distinguish block from
inline tags and behave accordingly. Thus, for example,
<sidebar>
hello
</sidebar>
will not be wrapped in `<para>` tags.
|
|
|
|
See bug #274, which was not completely fixed by the last patch.
|
|
|
|
It requires parsec 3, and currently pandoc can build with parsec 2.
|
|
Ported code from pandoc2.
Now all tests pass.
|
|
Also made simpleReferenceName parser more accurate, which
affects several other parsers.
|
|
These aren't valid in HTML, but many HTML files produced by
Windows tools contain them. We substitute correct unicode
characters.
|
|
If there's a subtitle, it is added to the title,
separated by a colon and linebreak. Closes #280.
|
|
Closes #279.
|
|
For example, in
Just a few glitches remaining.
<ul><li> In this situation, one loses the list.
</ul>
And in this, the preformatting.
<pre>Preformatted text not starting with its own blank line.
</pre>
Thansk to Dirk Laurie for noticing the issue.
|
|
Closes #274.
|
|
Textile reader: Make it possible to have colons after links.
|
|
|
|
* Skip spaces after <b>, <emph>, etc.
* Convert Plain elements into Para when they're in a list
item with Para, Pre, BlockQuote, CodeBlock.
An example of HTML that pandoc handles better now:
~~~~
<h4> Testing html to markdown </h4>
<ul>
<li>
<b> An item in a list </b>
<p> An introductory sentence.
<pre>
Some preformatted text
at this stage comes next.
But alas! much havoc
is wrought by Pandoc.
</pre>
</ul>
~~~~
Thanks to Dirk Laurie for reporting the issues.
|
|
|
|
|
|
Resolves Issue #304: problems with
(@item1; @item2)
because the final paren was being parsed as part of
the item key.
|
|
These previously caused infinite looping and stack overflows.
For example:
[^1]
[^1]: See [^1]
Note references are allowed in reST notes, so this isn't a full
implementation of reST. That can come later. For now we need to
prevent the stack overflows.
Partially resolves Issue #297.
|
|
|
|
So, in RST, 'http://google.com.' should be parsed as a link
to 'http://google.com' followed by a period.
The parser is smart enough to recognize balanced parentheses,
as often occur in wikipedia links: 'http://foo.bar/baz_(bam)'.
Also added ()s to RST specialChars, so '(http://google.com)'
will be parsed as a link in parens.
Added test cases.
Resolves Issue #291.
|
|
The bug affected field lists with multi-line items at the
end of the list.
|
|
The point of the change is to allow html tags to be used freely
at the left margin of a markdown+lhs document.
Thanks to Conal Elliot for the suggestion.
|
|
|
|
The last patch did not handle cases with > 4 spaces.
Also added a more general test case.
|
|
The problem was in input like this:
[^1]: note
not in note.
Also added a test case for this.
|
|
Previously a file beginning " hi" would cause a parse error.
Also cleaned up comment parsing.
|