This just parses inside smartTags and yields their contents,
ignoring the attributes of the smartTag. @jkr, you may want
to adjust this, but I wanted to get a fix in as fast as possible
for the dropped content.
Closes#2242; see also #3412.
* Renaming Text.Pandoc.Class.warn to addWarning avoids conflict
with Text.Pandoc.Shared.warn.
* Removed writeRTFWithEmbeddedImages from Text.Pandoc.Writers.RTF.
This is no longer needed; we automatically handle embedded images
using the PandocM functions. [API change]
In the past, the docx reader wrote an empty header as an empty list. It
should have the same width as a row (and be filled with empty cells).
(Note that I've reordered the code here slightly to get rid of a call to
`head`. It wasn't unsafe because it tested for null, but it was a bit of
a smell.)
Tables in MS Word are set by default to have special first-row
formatting, which pandoc uses to determine whether or not they have a
header. This means that one-row tables will, by default, have only a
header -- which we imagine is not what people want. This change
ensures that a one-row table is not understood to be a header only.
Note that this means that it is impossible to produce a header-only
table from docx, even though it is legal pandoc. But we believe that
in nearly all cases, it will be an accidental (and unwelcome) result
Closes#3285.
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.
Previously we only used the first anchor span to affect header ids. This
allows us to use all the anchor spans in a header, whether they're
nested or not.
Along with 62882f97, this closes#3088.
Previously we always generated an id for headers (since they wouldn't
bring one from Docx). Now we let it use an existing one if
possible. This should allow us to recurs through anchor spans.
Previously, we would only be able to figure out internal links to a
header in a docx if the anchor span was empty. We change that to read
the inlines out of the first anchor span in a header.
This still leaves another problem: what to do if there are multiple
anchor spans in a header. That will be addressed in a future commit.
We can't guarantee we'll convert every comment correctly, though we'll
do the best we can. This warns if the comment includes something other
than Para or Plain.
This adds simple track-changes comment parsing to the docx reader. It is
turned on with `--track-changes=all`. All comments are converted to
inlines, which can list some information. In the future a warning will
be added for comments with formatting that seems like it will be
excessively denatured.
Note that comments can extend across blocks. For that reason there are
two spans: `comment-start` and `comment-end`. `comment-start` will
contain the comment. `comment-end` will always be empty. The two will be
associated by a numeric id.
Previously, readDocx would error out if zip-archive failed. We change
the archive extraction step from `toArchive` to `toArchiveOrFail`, which
returns an Either value.
The docx reader used to use a Modifiable typeclass to combine both
Blocks and Inlines. But all the work was in the inlines. So most of the
generality was wasted, at the expense of making the code harder to
understand. This gets rid of the generality, and adds functions for
Blocks and Inlines. It should be a bit easier to work with going forward.
Change 5527465c introduced a `DummyListItem` type in Docx/Parse.hs. In
retrospect, this seems like it mixes parsing and iterpretation
excessively. What's *really* going on is that we have a list item
without and associate level or numeric info. We can decide what to do
what that in Docx.hs (treat it like a list paragraph), but the parser
shouldn't make that decision.
This commit makes what is going on a bit more explicit. `LevelInfo` is
now a Maybe value in the `ListItem` type. If it's a Nothing, we treat
it as a ListParagraph. If it's a Just, it's a normal list item.
* Bumped version to 1.16.
* Added Attr field to Link and Image.
* Added `common_link_attributes` extension.
* Updated readers for link attributes.
* Updated writers for link attributes.
* Updated tests
* Updated stack.yaml to build against unreleased versions of
pandoc-types and texmath.
* Fixed various compiler warnings.
Closes#261.
TODO:
* Relative (percentage) image widths in docx writer.
* ODT/OpenDocument writer (untested, same issue about percentage widths).
* Update pandoc-citeproc.
These come up when people create a list item and then delete the
bullet. It doesn't refer to any real list item, and we used to ignore
it.
We handle it with a DummyListItem type, which, in Docx.hs, is turned
into a normal paragraph with a "ListParagraph" class. If it follow
another list item, it is folded as another paragraph into that item. If
it doesn't, it's just its own (usually indented, and therefore
block-quoted) paragraph.
- The (non-exported) prelude is in prelude/Prelude.hs.
- It exports Monoid and Applicative, like base 4.8 prelude,
but works with older base versions.
- It exports (<>) for mappend.
- It hides 'catch' on older base versions.
This allows us to remove many imports of Data.Monoid
and Control.Applicative, and remove Text.Pandoc.Compat.Monoid.
It should allow us to use -Wall again for ghc 7.10.
This patch builds paragraph styles tree, then checks if paragraph has
style.styleId or style/name.val matching predetermined patterns.
Works with "Heading#" (name.val="heading #") for headings and
"Quote"|"BlockQuote"|"BlockQuotation" (name.val="Quote"|"Block Text")
for block quotes.
When we encounter one of the polyglot header styles, we want to remove
that from the par styles after we convert to a header. To do that, we
have to keep track of the style name, and remove it appropriately.
We're just keeping a list of header formats that different languages use
as their default styles. At the moment, we have English, German, Danish,
and French. We can continue to add to this.
This is simpler than parsing the styles file, and perhaps less
error-prone, since there seems to be some variations, even within a
language, of how a style file will define headers.
