summaryrefslogtreecommitdiff
path: root/sw/source/filter/ww8/wrtw8nds.cxx
diff options
context:
space:
mode:
authorJustin Luth <jluth@mail.com>2022-09-03 13:38:59 -0400
committerJustin Luth <jluth@mail.com>2022-09-04 03:16:40 +0200
commit449317473740d98338a61aca1e4ffb8821681c8e (patch)
tree7642a61dd7e11649c1b42dfe00111c93bb58551e /sw/source/filter/ww8/wrtw8nds.cxx
parentdc92a4d973086ce8a6a5f75ba0f4d4c9ca05537a (diff)
tdf#117994 doc: Revert "tdf#99474 close direct char fmt at end of para"
This reverts 5.1.4 commit 817c3b17fa57a7c4c4f80569bc00a21001fb6807 which fixes regression bug 17994 (in the summary line). Another reason for reverting it is tdf#150613 whose fix depends on getting this fixed first. Making any export changes based on the formatting of numbering is extremely dangerous, especially in this time period after LO 4.1 when a wonky patch made wild assumptions about what was best. Well, that patch was reverted in LO 7.3 for tdf#108518, and apparently obsoletes the usefulness this patch provided.. This patch that I'm reverting caused some visible regressions SEEN ONLY IN WORD which further confirms that we still have lots of wrong assumptions in regards to numbering formatting. I'm happy to see it reverts without causing any unit test failures even before I make any changes. I confirmed that reverting the 4.1 patch with 7.3 commit 343d4d32f00053bd72cfe240125835fe25ce264f was what allowed testTdf99474 to still pass. Change-Id: I4cf6fbfb3a4a2d483d9a500f13686ad4305742b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139334 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
Diffstat (limited to 'sw/source/filter/ww8/wrtw8nds.cxx')
-rw-r--r--sw/source/filter/ww8/wrtw8nds.cxx13
1 files changed, 7 insertions, 6 deletions
diff --git a/sw/source/filter/ww8/wrtw8nds.cxx b/sw/source/filter/ww8/wrtw8nds.cxx
index 185b01aead79..54a59b16e7f9 100644
--- a/sw/source/filter/ww8/wrtw8nds.cxx
+++ b/sw/source/filter/ww8/wrtw8nds.cxx
@@ -2386,6 +2386,7 @@ void MSWordExportBase::OutputTextNode( SwTextNode& rNode )
const OUString& aStr( rNode.GetText() );
sal_Int32 const nEnd = bNeedParaSplit ? *aBreakIt : aStr.getLength();
+ bool bIsEndOfCell = false;
bool bIncludeEndOfParaCRInRedlineProperties = false;
sal_Int32 nOpenAttrWithRange = 0;
@@ -2393,6 +2394,8 @@ void MSWordExportBase::OutputTextNode( SwTextNode& rNode )
if ( pTextNodeInfo )
{
pTextNodeInfoInner = pTextNodeInfo->getFirstInner();
+ if (pTextNodeInfoInner && pTextNodeInfoInner->isEndOfCell())
+ bIsEndOfCell = true;
}
do {
@@ -2702,6 +2705,9 @@ void MSWordExportBase::OutputTextNode( SwTextNode& rNode )
}
WriteCR( pTextNodeInfoInner );
+
+ if (0 != nEnd && bIsEndOfCell)
+ AttrOutput().OutputFKP(/*bforce=*/true);
}
}
}
@@ -2729,12 +2735,7 @@ void MSWordExportBase::OutputTextNode( SwTextNode& rNode )
"odd to see this happening, expected 0");
}
- // !bIncludeEndOfParaCRInRedlineProperties implies we have just
- // emitted a CR, in which case we want to pass force=true to
- // OutputFKP to ensure that an FKP entry for direct character
- // formatting is written even if empty, so that the next one will
- // start after the CR.
- AttrOutput().OutputFKP(!bIncludeEndOfParaCRInRedlineProperties);
+ AttrOutput().OutputFKP(/*bForce=*/false);
if (bTextAtr || bAttrWithRange || bIncludeEndOfParaCRInRedlineProperties)
{