summaryrefslogtreecommitdiff
path: root/sd
diff options
context:
space:
mode:
authorMiklos Vajna <vmiklos@collabora.com>2020-05-26 16:16:27 +0200
committerMiklos Vajna <vmiklos@collabora.com>2020-05-26 17:41:50 +0200
commit414586649582e182b2603702f4f586f4beeed8a9 (patch)
tree955f136eb395e94106697616299cd5a0c449988a /sd
parent2dd7c6a441f48a23dcbff1ebe24bdf21666c4ff0 (diff)
oox smartart import: fix aspect ratio of shape with composite algo
The layout node has alg=composite, then a parTx and a desTx child layout nodes. No matter what order is used (parent first, child first), the result will be wrong, as the constraints refer to each other. I did not spot any description in ISO 29500-1 that would describe what is the expected behavior. Researching this, found "One other consideration when specifying composite constraints is that the constraints must be specified in the same order as the nested layout nodes." at <http://web.archive.org/web/20111015151600/http://msdn.microsoft.com/en-us/magazine/cc163470.aspx>, which suggests to handle constraints for each shape in a parent -> child order, but keep a shared state when iterating over the children which gives us: - parent node, all direct constraints - for each child node: - child's constraints from parent - child's own constraints This way the desTx top value can depend on the parTx's height, and it's supported to define parTx's height only in the parTx layout node, not in the composite parent. And after all, it matches what PowerPoint does, so the column headings in the bugdoc have a 4:10 height:width aspect ratio. Change-Id: Ideb76c1ddd1ffff8d2a217cddf81106d1bb97eb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94872 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
Diffstat (limited to 'sd')
-rw-r--r--sd/qa/unit/data/pptx/fill-color-list.pptxbin41044 -> 42946 bytes
-rw-r--r--sd/qa/unit/import-tests-smartart.cxx10
2 files changed, 10 insertions, 0 deletions
diff --git a/sd/qa/unit/data/pptx/fill-color-list.pptx b/sd/qa/unit/data/pptx/fill-color-list.pptx
index 341233ad5f78..c88434952631 100644
--- a/sd/qa/unit/data/pptx/fill-color-list.pptx
+++ b/sd/qa/unit/data/pptx/fill-color-list.pptx
Binary files differ
diff --git a/sd/qa/unit/import-tests-smartart.cxx b/sd/qa/unit/import-tests-smartart.cxx
index 76659c0cf680..67db3deb4cc6 100644
--- a/sd/qa/unit/import-tests-smartart.cxx
+++ b/sd/qa/unit/import-tests-smartart.cxx
@@ -1488,6 +1488,16 @@ void SdImportTestSmartArt::testFillColorList()
// - Actual : 16225862 (0xf79646)
// i.e. the background of the "A" shape was orange-ish, rather than red-ish.
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(0xC0504D), nFillColor);
+
+ // Without the accompanying fix in place, this test would have failed with:
+ // - Expected: 2239
+ // - Actual : 5199
+ // i.e. the "A" shape's height/width aspect ratio was not 0.4 but rather close to 1.0, even if
+ // ppt/diagrams/layout1.xml's <dgm:constr type="h" refType="w" op="lte" fact="0.4"/> requested
+ // 0.4.
+ awt::Size aActualSize = xShape->getSize();
+ CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(2239), aActualSize.Height);
+
xDocShRef->DoClose();
}