diff options
| author | Justin Luth <justin.luth@collabora.com> | 2024-01-16 21:08:08 -0500 |
|---|---|---|
| committer | Miklos Vajna <vmiklos@collabora.com> | 2024-01-22 14:05:07 +0100 |
| commit | 12ea98fe637eda5f038b6447a5f0c5ea7104f448 (patch) | |
| tree | 390d0fcfb2ca5f0f2d63cf4b16194a229bddc36c /writerfilter | |
| parent | 71fed56e4a09fbf141fdb8f064df6764e6e6d262 (diff) | |
tdf#159158 tdf#120760 DOCX shape import: fix Z-order with behindDoc #2
This fixes documents where both a z-index and a relativeHeight are in
the hell-layer. z-indexes indicate behindDoc with a negative number,
so prior to this patch relativeHeights were always above z-indexes,
but in fact the reverse ought to be true.
The reason why this works so well is because relativeHeight
can be at maximum 1DFF FFFF, and we are subtracting 7FFF FFFF
which makes it a very low number that z-index is very
unlikely to ever reach.
I don't see any reason at all why this logic would be limited
to headers and footers. I assume that was done just to limit
the potential regression hate, but in that case a comment
should have been made stating that.
documentation: previous patchsets contain a list of unit tests
that have behindDoc without being in the HeaderFooter.
None were interesting...
The unit tests I modified were generally not surprising,
since I am changing the zOrder and getShapes() is based on zOrder,
so either refer to the shape by name when the order is not important
(and might change depending on ODT import, no z-index defined etc),
or else change the number to match the moved-to location
if it changed because of initial import.
The interesting one was the compat15 document which is
specified as behindDoc but that is supposed to be ignored...
perhaps if() could have just used m_bOpaque, but that is a logic
step a bit too far to take.
This can (and should) affect RTF as well, since
{\sn fBehindDocument}{\sv 1}
is documented as a shape consideration in the RTF spec.
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_behindDocA
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_behindDocB
Change-Id: Ic9eaecee28fd412f9aecce61b1e3a607f26d424a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162030
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Diffstat (limited to 'writerfilter')
| -rw-r--r-- | writerfilter/source/dmapper/GraphicImport.cxx | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/writerfilter/source/dmapper/GraphicImport.cxx b/writerfilter/source/dmapper/GraphicImport.cxx index 93ef346dcc99..b5f6d3385d58 100644 --- a/writerfilter/source/dmapper/GraphicImport.cxx +++ b/writerfilter/source/dmapper/GraphicImport.cxx @@ -386,6 +386,7 @@ public: void applyZOrder(uno::Reference<beans::XPropertySet> const & xGraphicObjectProperties) const { sal_Int32 nZOrder = m_zOrder; + bool bBehindText = m_bBehindDoc && !m_bOpaque; if (m_rGraphicImportType == GraphicImportType::IMPORT_AS_DETECTED_INLINE && !m_rDomainMapper.IsInShape()) { @@ -394,7 +395,7 @@ public: if (nZOrder >= 0) { // tdf#120760 Send objects with behinddoc=true to the back. - if (m_bBehindDoc && m_rDomainMapper.IsInHeaderFooter()) + if (bBehindText) nZOrder -= SAL_MAX_INT32; // TODO: it is possible that RTF has been wrong all along as well. Always true here? |