After round trip multiple occurrences of w:left, w:right etc
were exported.
Also added UT for the test file.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Change-Id: I6a503cf609f627b8f8eb9d33691e51582c15b459
Reviewed-on: https://gerrit.libreoffice.org/6608
Happens when we set "no number" in the default para style, which is
already the case for Writer anyway.
Change-Id: I3b262e633e52e4aae039c55d6edb744e36f0f354
When the DOCX exporter exported a table, it filled the table
column definitions with the column sizes of the FIRST row only.
This was ok for tables that have the same columns on all rows,
but for more complex tables with different cell widths - the
filter exported the wrong number of columns and the wrong width.
A followup fix would fix the rounding problems there still are
with the column widths that are exported in the table
definition.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Change-Id: Ie95dfe60b1c1811776433e457ca04e728623e01e
Reviewed-on: https://gerrit.libreoffice.org/6290
The XDocuments representing the DOM of an OOXML's customxml document is
stored as the PropertyValue "OOXCustomXml" into the "InteropGraBag".
Added mxCustomXmlDomList object which holds xDocuments for
each item.xml from CustomXml.
Exporting all items dom tree from customxml that has been parsed
when loading the file.
This is necessary in order to properly reopen docx files that
contain data like citation.
This fix grab bags only item[n].xml's files from CustomXml folder.
itemProps[n].xml's and item.xml's .rels are not preserved and exported yet.
(Working on this part)
Change-Id: I330f34f38a7aa4cd39094371bff15ebbc0318167
Reviewed-on: https://gerrit.libreoffice.org/6519
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's more consistent to do all the any to string conversion on the
import side. Also, when we have the ConvertColor calls in a single
place, audit grab-bag-related calls: those should always enable auto
color conversion.
Change-Id: I39ef74986617ee0ed629607e2a069047879b0422
The goal is to have clearer failure message by distinguishing
failures (only import, import and export, only export).
Change-Id: Ic4fc5f7bfd7c9ddb0705597c3fb994e41d04b5ba
Reviewed-on: https://gerrit.libreoffice.org/6289
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Handle wordWrap, beforeLines, afterLines, beforeAutospacing,
afterAutospacing, asciiTheme, hAnsiTheme, b, i, color, sz and vAlign.
With this, the export filter is now in sync with the import one again.
Change-Id: I7184447baf872374eaa69afdfcb149a7e6e45faa
In theory, it was a problem to have the table cursor around when having
the selection outside the table; but it didn't cause a problem so far.
However, when the table has one or more empty cells, we really need to
leave table mode, otherwise only the table gets selected.
Change-Id: I766903ed624b9338f0612697b4c03f44de1d2e41
This bug fix is for roundtripping a DOCX that has
a specific 'start value' for the page numbers.
In most cases LO imports it ok.
However - until now - Word allowed you to start page number
from 0, while LO only allowed starting page numbers from 1.
This was because the 'start value' was stored in an 'unsigned int',
and the value '0' was used to mark 'there is no start value'.
This patch changes the way the 'start value' is stored
from 'unsigned int' to 'optional unsigned int'.
This way - if there is no value applied - the variable will hold NULL.
However - if a value is set - it can be 0 or more.
This meant also tweaking all the places that used to get this value,
so that now they handle an 'optional uint', instead of a 'uint'.
Conflicts:
sw/source/ui/inc/break.hxx
sw/source/ui/inc/wrtsh.hxx
sw/source/ui/shells/textsh1.cxx
sw/source/ui/utlui/uitool.cxx
sw/source/ui/wrtsh/wrtsh1.cxx
Change-Id: I6ad9d90e03b42c58eed2271477df43c20ad6f20a
Reviewed-on: https://gerrit.libreoffice.org/5681
Pictures typically have a single RTF group, so we imported them at the
end of that group. Though multiple inner groups are also allowed, so
make sure we only do the import at the very end, instead of at the end
of all inner groups as well, resulting in multiple (fake) pictures.
Regression from 13c00ce322 (Enable the
writerfilter-based RTF import in non-experimental mode, 2011-08-18).
Change-Id: Id895b2c6d3b824d09d89bfa01ce59aba76c55d42
The "ooxmlexport" unit test for Smart-Art has been updated to just
check for the new rendered bitmap that substitutes the generated basic
shapes.
The "ooxmlimport" has been updated with a new "testSmartart" unit
tests which checks that the importing has been done to just basic
shapes.
For this, the "run" method has been customized so we can set the
proper filter option.
Slightly modified the expected results in the "testChartProp" unit
test since linking it to additional libraries has modified the
dimmensions of the imported chart in few units.
Made the "ooxmlimport" C++ unit tests in the "sw" module to depend on
the "drawinglayer" and "svx" components and the "utl" library.
Conflicts:
sw/qa/extras/ooxmlimport/ooxmlimport.cxx
Change-Id: I0900a50cfee07999511d071bc9932477ad9430c5
Problem Description: In case of multicolumn sections, separator line was getting added during export to docx.
Unit test cases added to verify the code changes.
Change-Id: Id65ac4d3878eed298882c85082cec9575f914d83
Reviewed-on: https://gerrit.libreoffice.org/6211
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This used to be problematic due to the flashing windows, but it was
stated recently that we already have those anyway due to e.g. gengal. It
turns out all our DOCX filter tests pass just fine on Mac, except one
checksum test -- make *that* an exception instead.
Change-Id: Id5e620a33b9b05f154e4072a8a49f335837079ea
Commit 542a0d7260 (#100044# Cleanup for
optimization defines->enums, 2002-08-14) added the problematic "else"
without mentioning the reason, so I assume it's safe to just revert that
part.
Change-Id: Id90fbdfb1116be458a76c9653fec0633edc34fac
.. paragraph style
The original problem (from a user's point of view) was that the second
level of the numbering started from 1.1 instead of 2.1 in the bugdoc.
This was fixed by using outline numbering for level 2 as well, but this
is problematic in many cases: we want to have outline numbering exactly
when outline numbering is enabled for the given paragraph style.
So revert the change in SwWW8ImplReader::SetStylesList() and fix it
differently: SwWW8ImplReader::RegisterNumFmtOnStyle() explicitly ignores
list style if outline numbering is available with no good reason. Both
the WW8 format and Writer core allows to have outline numbering and a
list style at the same time, so set list style even when outline
numbering is available. This fixes the original issue, too -- without
introducing nasty fake outline numbering usage.
Also add a testcase for the original issue.
(regression from e3d5c3e074)
Change-Id: Id7d2d67a96a858aee3230110cb518fea51d19d38
There are various cases here, as a start just test that any spellcheck
popup menu in a redlined document should at least contain the "go to
prev/next change" menu items.
Change-Id: Ic70b6dae4cac8fd970ad54e5015a61d50b024b2b
If there were spelling errors in a text portion that is to be
accepted/rejected, right mouse click just shown the spellcheck menu, so
oddly if an inserted text contained spelling mistakes and we wanted to
reject them, Writer didn't allow that.
Fix this by adding the redline operations (accept change, reject change,
next change, previous change) to the spellcheck menu, but make it only a
wrapper around the SwView code, so all the logic on what to do and when
to hide these menu items is not duplicated.
Change-Id: I76cad2f58a47575f8ef9517af51f1ffe7c4b6844
