Age | Commit message (Collapse) | Author | Files | Lines |
|
This regression leads to the introduction of empty rows
in some circumstances.
Closes #3280.
|
|
+ Removed Text.Pandoc.Readers.Docx.Fonts
+ Moved its code to texmath; we now use (from texmath 0.9)
Text.TeXMath.Unicode.Fonts
+ Use texmath 0.9 (currently from git).
+ Updated epub tests because texmath now handles more mathml.
|
|
We now check explicitly for non-1 rowspan or colspan
attributes, and fail when we encounter them. Previously
we checked that each row had the same number of cells,
but that could be true even with rowspans/colspans.
And there are cases where it isn't true in tables that
we can handle fine -- e.g. when a tr element is empty.
So now we just pad rows with empty cells when needed.
Closes #3027.
|
|
ODT's reader always put empty captions for the parsed
tables. This commit
1) checks paragraphs that follow the table definition
2) treats specially a paragraph with a style named 'Table'
3) does some postprocessing of the paragraphs that combines
tables followed immediately by captions
The ODT writer used 'TableCaption' style name for the caption
paragraph. This commit follows the open office approach which
allows for appending captions to table but uses a built-in style
named 'Table' instead of 'TableCaption'. Any users of odt format
(both writer and reader) are therefore required to change the
style's name to 'Table', if necessary.
|
|
Fixed an error which came up, for example, with `\vspace`
inside a caption. (Captions expect inlines.)
Closes #3256.
|
|
Table column properties can optionally specify a column's width with
which it is displayed in the buffer. Some exporters, notably the ODT
exporter in org-mode v9.0, use these values to calculate relative column
widths. The org reader now implements the same behavior.
Note that the org-mode LaTeX and HTML exporters in Emacs don't support
this feature yet, which should be kept in mind by users who use the
column widths parameters.
Closes: #3246
|
|
This allows use of things like `\only<2,3>{my content}` in
Markdown that is going to be converted to beamer.
Closes #3184.
|
|
We can now parse all of the tables emitted by pandoc in
our tests.
The only thing we don't get yet are alignments and
column widths in more complex tables.
See #2669.
|
|
|
|
Remove whitespace before function documentation The extra spaced cause
problems with documentation tools and Travis tests are failing because
of this.
|
|
Reader can now parse simple LaTeX tables such as those
generated by pandoc itself.
We still can't handle pandoc multiline tables which involve
minipages and column widths.
Partially addresses #2669.
|
|
It previously only worked when the qnames lacked the docbook
namespace URI.
|
|
This fixes a regression introduced in
7e5220b57c5a48fabe6e43ba270db812593d3463.
|
|
* Markdown reader: modify bracketedSpan to check small caps
* MANUAL.txt: add description on the use of `bracketed_spans` in small cap
* Improve markdown readers: bracketedSpan function EXACTLY as spanHtml
|
|
|
|
Otherwise treat as span.
Closes #3226.
|
|
We wrap `[CHART]` in a `<span class="chart">`. Note that it maps to
inlines because, in docx, anything in a drawing tag can be part of a
larger paragraph.
|
|
We not only want "w:drawing", because that could also include
charts. Now we specify "w:drawing"//"pic:pic". This shouldn't change
behavior at all, but it's a first step toward allowing other sorts of
drawing data as well.
|
|
Images which are the only element in a paragraph can still be given HTML
attributes, even if the image does not have a caption and is hence not a figure.
The following will add set the `width` attribute of the image to `50%`:
#+ATTR_HTML: :width 50%
[[file:image.jpg]]
Closes: #3222
|
|
When a piece of text has a text 'Source_Text' then
we assume that this is a piece of the document
that represents a code that needs to be inlined.
Addapted an odt writer to also reflect that change;
previously it was just writing a 'preformatted' text using
a non-distinguishable font style.
Code blocks are still not recognized by the ODT reader.
That's a separate issue.
|
|
...if citations extension disabled. Example: in
[link text][@a]
[@a]: url
`link text` isn't hyperlinked because `[@a]` is parsed as a citation.
Previously this happened whether or not the `citations` extension was
enabled. Now it happens only if the `citations` extension is enabled.
Closes #3209.
|
|
|
|
We use the "description" field as alt text and the "title" field as
title. These can be accessed through the "Format Picture" dialog in
Word.
|
|
Previously, if given an empty namespace:
(elemName ns "" "foo")
`elemName` would output a QName with a `Just ""` namespace. This is
never what we want. Now we output a `Nothing`. If someone *does* want a
`Just ""` in the namespace, they can enter the QName value explicitly.
|
|
unless something else is explicitly specified in xmlns.
Provided it parses as MathML, of course.
Also fixed default which should be to inline math if no
display attribute is used.
|
|
|
|
|
|
ODT reader simply provided an empty header list
which meant that the contents of the whole table,
even if not empty, was simply ignored.
While we still do not infer headers we at least have
to provide default properties of columns.
|
|
Fixes cases like:
\begin{center}
\begin{tikzpicture}[baseline={([yshift=+-.5ex]current bounding box.center)}, level distance=24pt]
\Tree [.{S} [.NP John\index{i} ] [.VP [.V likes ] [.NP himself\index{i,*j} ]]]
\end{tikzpicture}
\end{center}
|
|
Special blocks (i.e. blocks with unrecognized names) can be prefixed
with an `ATTR_HTML` block attribute. The attributes defined in that
meta-directive are added to the `Div` which is used to represent the
special block.
Closes: #3182
|
|
The `todo` export option allows to toggle the inclusion of TODO keywords
in the output. Setting this to `nil` causes TODO keywords to be dropped
from headlines. The default is to include the keywords.
|
|
Headlines can have optional todo-markers which can be controlled via the
`#+TODO`, `#+SEQ_TODO`, or `#+TYP_TODO` meta directive. Multiple such
directives can be given, each adding a new set of recognized todo-markers.
If no custom todo-markers are defined, the default `TODO` and `DONE`
markers are used.
Todo-markers are conceptually separate from headline text and are hence
excluded when autogenerating headline IDs.
The markers are rendered as spans and labelled with two classes: One
class is the markers name, the other signals the todo-state of the
marker (either `todo` or `done`).
|
|
|
|
[API change]
|
|
This is needed because github flavored Markdown has a slightly
different set of escapable symbols than original Markdown;
it includes angle brackets.
Closes #2846.
|
|
Closes #3150.
Thanks to @lep for the bug report and patch.
|
|
Latex Writer only handles captions if the image's title
is prefixed with 'fig:'.
|
|
Issue 3143: Don't duplicate text for anchors
|
|
[odt] images parser
|
|
|
|
@tarleb this is an interesting one, see the build log in
https://travis-ci.org/jgm/pandoc/jobs/168612017
It only failed on ghc 7.8; I think this must have to do with
the change making Monad a superclass of Applicative, hence
this change.
|
|
When creating an anchor element we were adding its representation
as well as the original content, leading to text duplication.
|
|
|
|
Frame can contain other frames with the text boxes.
This is something that has not been considered before
and meant that the whole construction of images was
broken in those cases. Also the captions were fixed/ignored.
|
|
RST requires a space before a footnote marker. We discard those spaces
so that footnotes will be adjacent to the text that comes before
it. This is in line with what rst2latex does. rst2html does not discard
the space, but its html output is different than pandoc's, so this seems
the most semantically correct approach.
Closes #3163
|
|
A `#+CAPTION` attribute before an image is enough to turn an image into a
figure. This wasn't the case because the `parseFromString` function, which
processes the caption value, would fail on empty values. Adding a newline
character to the caption value fixes this.
Fixes: #3161
|
|
[ODT Parser] Include list's starting value
|
|
Review revealed that we didn't handle the case
when the starting point is an empty string. While
this is not a valid .odt file, we simply added
a special case to deal with it.
Also added tests for the new feature.
|
|
Markup-features focusing on lines as distinctive part of the markup are read
into `LineBlock` elements. This currently means line blocks in reStructuredText
and Markdown (the latter only if the `line_block` extension is enabled), the
`linegroup`/`line` combination from the Docbook 5.1 working draft, and Org-mode
`VERSE` blocks.
|
|
Previously the starting value of the lists' items has been
hardcoded to 1. In reality ODT's list style definition can
provide a new starting value in one of its attributes.
Writers already handle the modified start value so no need
to change anything in that area.
|