summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMiklos Vajna <vmiklos@collabora.co.uk>2016-04-08 17:18:55 +0200
committerMiklos Vajna <vmiklos@collabora.co.uk>2016-04-08 16:07:49 +0000
commitfd61dee6457a44687f1142dd55bfee6b64fda2ef (patch)
treec748ccd5a8a98cc891f7d84d4ff878e8cf0c374e
parentb98f2cc3cf8bd2721ec8118af64edd3424c69dc2 (diff)
tdf#99140 DOCX import: fix table horizontal aligment to be 'from left' ...
... when it was 'manual'. Regression from commit c1e563f6efd09cd3463f1b92a3022ae288c92087 (fdo#76741 [DOCX] Table Alignment and width type, 2014-04-04), DOCX import code had to deal with two kinds of horizontal alignment when it came to floating tables: the alignment of the table itself, and the alignment of the float parameters. The problem is, in general it's wanted that the table is aligned according to the floating parameters, but in Writer the "from left" UI setting is described differently for tables and fly frames: tables use LEFT_AND_WIDTH for that, while fly frames use NONE. Fix the problem by touching the default only in case the floating parameters have something that's different from NONE. With this, the width of tables is no longer lost when they are described to be floating ones in the DOCX markup, but FloatingTableConversion() decides to ignore that. Change-Id: Idd41c3e03e6ded8552e9d15b6080e4b45eb18d3d Reviewed-on: https://gerrit.libreoffice.org/23923 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
-rw-r--r--sw/qa/extras/ooxmlimport/ooxmlimport.cxx6
-rw-r--r--writerfilter/source/dmapper/DomainMapperTableHandler.cxx13
2 files changed, 13 insertions, 6 deletions
diff --git a/sw/qa/extras/ooxmlimport/ooxmlimport.cxx b/sw/qa/extras/ooxmlimport/ooxmlimport.cxx
index da3ccc7db741..d838edb08553 100644
--- a/sw/qa/extras/ooxmlimport/ooxmlimport.cxx
+++ b/sw/qa/extras/ooxmlimport/ooxmlimport.cxx
@@ -3231,6 +3231,12 @@ DECLARE_OOXMLIMPORT_TEST(testTdf99140, "tdf99140.docx")
uno::Reference<drawing::XDrawPage> xDrawPage = xDrawPageSupplier->getDrawPage();
// This was 1: a multi-page floating table was imported as a TextFrame.
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(0), xDrawPage->getCount());
+
+ uno::Reference<text::XTextTablesSupplier> xTablesSupplier(mxComponent, uno::UNO_QUERY);
+ uno::Reference<container::XIndexAccess> xTables(xTablesSupplier->getTextTables(), uno::UNO_QUERY);
+ uno::Reference<beans::XPropertySet> xTableProperties(xTables->getByIndex(1), uno::UNO_QUERY);
+ // This was text::HoriOrientation::NONE, the second table was too wide due to this.
+ CPPUNIT_ASSERT_EQUAL(text::HoriOrientation::LEFT_AND_WIDTH, getProperty<sal_Int16>(xTableProperties, "HoriOrient"));
}
CPPUNIT_PLUGIN_IMPLEMENT();
diff --git a/writerfilter/source/dmapper/DomainMapperTableHandler.cxx b/writerfilter/source/dmapper/DomainMapperTableHandler.cxx
index 91a797a98872..c16282e66e09 100644
--- a/writerfilter/source/dmapper/DomainMapperTableHandler.cxx
+++ b/writerfilter/source/dmapper/DomainMapperTableHandler.cxx
@@ -281,20 +281,21 @@ bool lcl_extractTableBorderProperty(PropertyMapPtr pTableProperties, const Prope
return false;
}
-}
-
-bool lcl_extractHoriOrient(std::vector<beans::PropertyValue>& rFrameProperties, sal_Int32& nHoriOrient)
+void lcl_extractHoriOrient(std::vector<beans::PropertyValue>& rFrameProperties, sal_Int32& nHoriOrient)
{
// Shifts the frame left by the given value.
for (size_t i = 0; i < rFrameProperties.size(); ++i)
{
if (rFrameProperties[i].Name == "HoriOrient")
{
- nHoriOrient = rFrameProperties[i].Value.get<sal_Int32>();
- return true;
+ sal_Int32 nValue = rFrameProperties[i].Value.get<sal_Int32>();
+ if (nValue != text::HoriOrientation::NONE)
+ nHoriOrient = nValue;
+ return;
}
}
- return false;
+}
+
}
void lcl_DecrementHoriOrientPosition(std::vector<beans::PropertyValue>& rFrameProperties, sal_Int32 nAmount)