This requires an updated version of pandoc-types that
introduces PageBreak definition.
Not that this initial commit only introduces ODT pagebreaks
and distinguishes for it page breaks before, after, or both,
the paragraph, as read from the style definition.
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.
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.
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.
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.
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.
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.
Don't use custom prelude for latest ghc.
This is a better approach to making 'stack ghci' and 'cabal repl'
work. Instead of using NoImplicitPrelude, we only use the custom
prelude for older ghc versions. The custom prelude presents a
uniform API that matches the current base version's prelude.
So, when developing (presumably with latest ghc), we don't
use a custom prelude at all and hence have no trouble with ghci.
The custom prelude no longer exports (<>): we now want to
match the base 4.8 prelude behavior.
- 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.
