The document had 3 sections, separated by continuous section breaks.
Previously only margins from the last section were imported, this way
the first page had default margins.
Now margins are also applied when we hit continuous section breaks. This
way margin values from the last section break affecting the page wins. A
later commit could improve this further by setting the minimum of these
and setting a section margin for each non-minimal sections.
Change-Id: I4d9a4585e795220533909bd1d467d933caaa0d71
MSVC misinterprets UTF-8 source code without BOM as ANSI/OEM codepage.
For that reason if local codepage is unfriendly to UTF-8, it sometimes
causes compilation error.
Change-Id: I8acd5500e581e020fd60b5a2ec20629f92fdf87c
This is the RTF equivalent of f5b7acac624f07fa95835b6054b8d295901bb1dd,
which avoided TO_PAGE-anchored shapes in the VML importer.
Change-Id: I58a5cdb311ac43ddba00bc441005fb37a4899cee
Instead of unconditionally calling addProperty(), first check the
existence with hasPropertyByName() and call setPropertyValue() instead,
if necessary.
Change-Id: Ie0a075bbfe6eaa1f66726c456105dcdef9001d30
Both Word and Writer typically write all paragraph properties before the
first text in each paragraph, but at least for paragraph alignment, it's
valid to write them at the end.
Change-Id: I0337e63678ad45c662a204ab2fc59378607abe74
This crashed because for a single listoverride entry 2 SPRMs were sent
to the domain-mapper, and the second one was empty.
Change-Id: Ic41ffd8bd4edcff065f49ecef3464efedd909d63
In case we have a table of a given width and the second (or later) row
has fewer cells, we have to add a fake cell to such a row. However, it
doesn't make sense to do this when the difference is only a few twips:
we can't create such a small frame inside the cell later anyway.
Regression from c3b0f13546b30e5db3aecd311c7178e4e0933208.
Change-Id: Ibc0f02d4184b58bd423c3405e786e1ec25b9dd13
The bugfix was just for the special case when we must create textframes
due to the contained tables, this one add support for the default case
when we want a real group shape.
Change-Id: I74b77b233235959266a24660c970a79e41d8b272
In case we have a \sect, there was no \sbknone (so it counts as a page
break as well) and there is nothing after it, we should not make extra
efforts to make that have some effect, but adding at least one empty
paragraph to that new page.
Change-Id: Ibcbecabcb590ed34ef96a97698e4ab8f638d3483
There were multiple problems here:
- \f had a special handler for the listlevel destination, \af had not
- in case of multiple \f or \af, the first one is used for the bullet
font
- in case only \af is used for the bullet font, its value should be used
for \f as well
Change-Id: I6631504c1aa9f2e0792a3469a5fdce5b7bd49518
There are two cases here: if the shapes contain tables (or other
Writer-specific features), we should use text frames and we should not
create the actual group shape, as Writer textframes can't be part of
such group shapes. The other case is when the shapes contain simple
text, OTOH there are groupshape-level transformations defined, in that
case we should choose drawinglayer rectangles and actually create a
group shape.
This commit implements support for the first case only.
Change-Id: I9dc99b0711ce5c7a29ea0b14539df0121f9de3d0
E.g. 0,1 was imported as 1,0, as we did not differentiate between not
having the coordinate yet and having it as zero.
Change-Id: Ia5fbbcc791dc9c6866ffd4c146793690661d81b4
That destination contains a whole shape, but the only interesing detail
of it is the fill color, which is the page background color.
Change-Id: I9527db8954c48c980f8734c9bbeaa6ccd3c48fbc
Make sure that at least full-page-width multi-page floating tables are
imported on multiple pages.
Change-Id: Ifb974d50c50b1495634ac2652a3ae46235bb5f52
There were two problems here:
- Writer textframes don't have an AnchorPosition property, use
compareRegionStarts() instead
- turns out DOC/DOCX import doesn't create Write textframes when the
shape has no text, doing so in the RTF import fixes the other two
testcase as well.
Change-Id: Ib2b4a0b7f8317d300fd532daea22568e33eceb53
I'm not sure yet if the tests should be updated or they signal real
problems, I'll came back to this later.
Change-Id: Ie2570f01e07e557281d2577471a49a730a894393
Regression from 4a507f732d82c188ad81b022cbe3037951e58ac3. The problem
was that in some cases \pard can't reset all paragraph properties. The
original commit just made this keyword a noop when it occurred between
\cell and \row, but this is too much. At least margins do need
resetting.
Change-Id: I5cbb1df72bf1211f85ef69ab64d5b46cbce5c742
Word typically uses the Symbol font to describe bullet characters
instead of using a sane Unicode value, the previous can only be handled
if we parse the custom font set for the list.
Change-Id: I1491f07c40953949e381a035c1596c207cdc4c35
There were two issues here:
1) c3b0f13546b30e5db3aecd311c7178e4e0933208 added a mechanism to work
around broken documents, but that didn't deal with nested tables.
Additionally, the check compared the max row width with the width of the
last cell, not the last row.
2) d276d3f3ae112a11c8cb5768650d147cbb94275e cleaned up implicit
horizontal merge detection, but didn't deal with valid documents, where
each row definition is available twice.
Change-Id: I1a32ec2fcb0d1a8fca7a7bd26501d3daf17880c9
"Required line break" was eaten by the newly added code in text() to
ignore \'0a. (regression from f593a2e4179b05ae1019372cde612cb242d1d27f)
Change-Id: Id32687c40a17ddb99196635cedfc850182705799
