[Libreoffice-commits] core.git: Branch 'libreoffice-7-1' - sw/qa sw/source writerfilter/source
sw/qa/extras/ooxmlexport/data/effect-extent-line-width.docx |binary
sw/qa/extras/ooxmlexport/ooxmlexport16.cxx | 21 +++
sw/source/filter/ww8/docxsdrexport.cxx | 11 +++
writerfilter/source/dmapper/GraphicImport.cxx | 36 ++--
4 files changed, 63 insertions(+), 5 deletions(-)
New commits:
commit ea6193d64c5bed72bfb919b782434a0b3674c525
Author: Miklos Vajna
AuthorDate: Tue Mar 16 09:05:57 2021 +0100
Commit: Xisco Fauli
CommitDate: Thu Mar 18 14:10:26 2021 +0100
tdf#138895 DOCX filter: fix handling for effect extent vs line width
Regression from commit a5a836d8c43dc9cebbbf8af39bf0142de603a7c6 (DOCX
filter: effect extent should be part of the margin, 2014-12-04), the
problem was that effect extent is OK to be added as an extra margin, but
line width is part of that effect extent in Word, so Writer margin
should not be increased with the line width.
The Word behavior seems to be that half of the line width is part of
e.g. the top effect extent, then the other half is part of the bottom
one (and so on).
The bugdoc's case was that a too large margin shifted the last line
below the shape, and this tiny half-line-width extra margin handled
correctly puts the line back to its correct place.
Change-Id: Ic897926f3d79f979ea84aef3dbda49c46b18a3ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112558
Reviewed-by: Miklos Vajna
Tested-by: Jenkins
Signed-off-by: Xisco Fauli
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112582
diff --git a/sw/qa/extras/ooxmlexport/data/effect-extent-line-width.docx
b/sw/qa/extras/ooxmlexport/data/effect-extent-line-width.docx
new file mode 100644
index ..5cc4d4e374ee
Binary files /dev/null and
b/sw/qa/extras/ooxmlexport/data/effect-extent-line-width.docx differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
index f532794e3874..a397bb073ecf 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
@@ -74,6 +74,27 @@ DECLARE_OOXMLEXPORT_EXPORTONLY_TEST(testFooterMarginLost,
"footer-margin-lost.do
assertXPath(pXmlDoc, "/w:document/w:body/w:sectPr/w:pgMar", "footer",
"709");
}
+CPPUNIT_TEST_FIXTURE(Test, testEffectExtentLineWidth)
+{
+auto verify = [this]() {
+CPPUNIT_ASSERT_EQUAL(static_cast(508),
+ getProperty(getShape(1), "TopMargin"));
+};
+
+// Given a document with a shape that has a non-zero line width and effect
extent:
+// When loading the document:
+load(mpTestDocumentPath, "effect-extent-line-width.docx");
+// Then make sure that the line width is not taken twice (once as part of
the margin, and then
+// also as the line width):
+// Without the accompanying fix in place, this test would have failed with:
+// - Expected: 508
+// - Actual : 561
+// i.e. the upper spacing was too large, the last line of the text moved
below the shape.
+verify();
+reload(mpFilter, "effect-extent-line-width.docx");
+verify();
+}
+
DECLARE_OOXMLEXPORT_EXPORTONLY_TEST(testTdf140572_docDefault_superscript,
"tdf140572_docDefault_superscript.docx")
{
// A round-trip was crashing.
diff --git a/sw/source/filter/ww8/docxsdrexport.cxx
b/sw/source/filter/ww8/docxsdrexport.cxx
index 8d68eb5da6f7..bcf2959dd149 100644
--- a/sw/source/filter/ww8/docxsdrexport.cxx
+++ b/sw/source/filter/ww8/docxsdrexport.cxx
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
using namespace com::sun::star;
using namespace oox;
@@ -447,22 +448,32 @@ void DocxSdrExport::startDMLAnchorInline(const
SwFrameFormat* pFrameFormat, cons
}
}
attrList->add(XML_behindDoc, bOpaque ? "0" : "1");
+sal_Int32 nLineWidth = 0;
+if (const SdrObject* pObject = pFrameFormat->FindRealSdrObject())
+{
+nLineWidth = pObject->GetMergedItem(XATTR_LINEWIDTH).GetValue();
+}
+
// Extend distance with the effect extent if the shape is not rotated,
which is the opposite
// of the mapping done at import time.
// The type of dist* attributes is unsigned, so make sure no negative
value is written.
sal_Int64 nTopExtDist = nRotation ? 0 : nTopExt;
+nTopExtDist -= TwipsToEMU(nLineWidth / 2);
sal_Int64 nDistT = std::max(static_cast(0),
TwipsToEMU(aULSpaceItem.GetUpper()) -
nTopExtDist);
attrList->add(XML_distT, OString::number(nDistT).getStr());
sal_Int64 nBottomExtDist = nRotation ? 0 : nBottomExt;
+nBottomExtDist -= TwipsToEMU(nLineWidth / 2);
sal_Int64 nDistB = std::max(static_cast(0),
TwipsToEMU(aULSpaceItem.GetLower()) -
nBottomExtDist);
attrList->add(XML_distB,
[Libreoffice-commits] core.git: Branch 'libreoffice-7-1' - sw/qa sw/source writerfilter/source
sw/qa/extras/rtfexport/data/tdf137894.odt |binary
sw/qa/extras/rtfexport/rtfexport5.cxx | 16 ++
sw/source/filter/ww8/rtfattributeoutput.cxx | 138
sw/source/filter/ww8/rtfattributeoutput.hxx |6 -
writerfilter/source/rtftok/rtfdispatchvalue.cxx |4
5 files changed, 95 insertions(+), 69 deletions(-)
New commits:
commit efe85aa1ef4034ae70c50a256b491737199b8747
Author: Mark Hung
AuthorDate: Sun Nov 22 19:32:32 2020 +0800
Commit: Xisco Fauli
CommitDate: Wed Nov 25 18:17:43 2020 +0100
tdf#137894 separate associated character properties
in ww8filter/RtfAttributeOutput and treat \dbch as
CJK and \hich Western in order to roundtrip the
RTF document.
ww8filter mix all the associated style, including
properties for CJK and CTL scripts.
Both RtfAttributeOutput::CharFontCJK and
RtfAttributeOutput::CharFontCTL output \dbch,
that result in incorrect assocation.
CharFontCTL should use \rtlch, but it was already in
RtfAttributeOutput::MoveCharacterProperties.
To make the order correct, I separate the
associated character properties that were
stored in m_aSyltesAssoc into m_aSyltesAssocRtlch,
and m_aSyltesAssocDbch by their script types.
Note that it is not clear what associated character
properties that we should adopt for \hich and \ltrch.
In theory RTL scripts can output high ANSI chars too,
so \hich may get properties from either Western or
CTL scripts. However, examining Hebrew RTF documents,
I didn't see any sign that \hich is used in that way.
Use RTL as CTL might be a problem for Mongolian,
Manchu and Xibe. They are CTL but top-to-bottom (aka LTR)
. But I don't think they will be expressed
as high ANSI chars either.
Change-Id: I214edbb00a67c2ffe19c5a37254c8988a0828f40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106355
Tested-by: Jenkins
Reviewed-by: Miklos Vajna
(cherry picked from commit f97af19460fbd7483a0e1c1d0137e814f5390e69)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106523
Reviewed-by: Xisco Fauli
diff --git a/sw/qa/extras/rtfexport/data/tdf137894.odt
b/sw/qa/extras/rtfexport/data/tdf137894.odt
new file mode 100755
index ..79c7eb178a7f
Binary files /dev/null and b/sw/qa/extras/rtfexport/data/tdf137894.odt differ
diff --git a/sw/qa/extras/rtfexport/rtfexport5.cxx
b/sw/qa/extras/rtfexport/rtfexport5.cxx
index a48adfa653cd..0d921ed6c7b6 100644
--- a/sw/qa/extras/rtfexport/rtfexport5.cxx
+++ b/sw/qa/extras/rtfexport/rtfexport5.cxx
@@ -1260,6 +1260,22 @@ DECLARE_RTFEXPORT_TEST(testTdf138210, "tdf138210.rtf")
CPPUNIT_ASSERT_EQUAL(sal_Int32(1), xIndexAccess->getCount());
}
+DECLARE_RTFEXPORT_TEST(testTdf137894, "tdf137894.odt")
+{
+lang::Locale locale1(getProperty(getRun(getParagraph(1), 1),
"CharLocaleAsian"));
+CPPUNIT_ASSERT_EQUAL(OUString("ja"), locale1.Language);
+CPPUNIT_ASSERT_EQUAL(OUString("MS UI Gothic"),
+ getProperty(getRun(getParagraph(1), 1),
"CharFontNameAsian"));
+CPPUNIT_ASSERT_EQUAL(20.f, getProperty(getRun(getParagraph(1), 1),
"CharHeightAsian"));
+CPPUNIT_ASSERT_EQUAL(OUString("Mangal"),
+ getProperty(getRun(getParagraph(1), 1),
"CharFontNameComplex"));
+CPPUNIT_ASSERT_EQUAL(20.f, getProperty(getRun(getParagraph(1), 1),
"CharHeightComplex"));
+lang::Locale locale2(
+getProperty(getRun(getParagraph(2), 1),
"CharLocaleComplex"));
+CPPUNIT_ASSERT_EQUAL(OUString("he"), locale2.Language);
+CPPUNIT_ASSERT_EQUAL(32.f, getProperty(getRun(getParagraph(2), 1),
"CharHeightComplex"));
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sw/source/filter/ww8/rtfattributeoutput.cxx
b/sw/source/filter/ww8/rtfattributeoutput.cxx
index 9e76b3d3fd48..23dc3af728e2 100644
--- a/sw/source/filter/ww8/rtfattributeoutput.cxx
+++ b/sw/source/filter/ww8/rtfattributeoutput.cxx
@@ -423,49 +423,58 @@ void RtfAttributeOutput::EndRunProperties(const
SwRedlineData* /*pRedlineData*/)
OString RtfAttributeOutput::MoveCharacterProperties(bool aAutoWriteRtlLtr)
{
-const OString aAssoc = m_aStylesAssoc.makeStringAndClear();
+const OString aAssocHich = m_aStylesAssocHich.makeStringAndClear();
+const OString aAssocDbch = m_aStylesAssocDbch.makeStringAndClear();
+const OString aAssocRtlch = m_aStylesAssocRtlch.makeStringAndClear();
+const OString aAssocLtrch = m_aStylesAssocLtrch.makeStringAndClear();
const OString aNormal = m_aStyles.makeStringAndClear();
OStringBuffer aBuf;
if (aAutoWriteRtlLtr && !m_bControlLtrRtl)
{
-m_bControlLtrRtl = !aAssoc.isEmpty();
+m_bControlLtrRtl = !aAssocRtlch.isEmpty();
m_bIsRTL = false;
m_nScript = i18n::ScriptType::LATIN;
}
-if (m_bControlLtrRtl)
+if (m_bIsRTL)
{
-
