tdf#136929 docx export: keep frame with paragraph

EndParagraph was checking if any frames were to be
attached. Well, startParagraph can occur multiple
times before endParagraph, so the frames can be
attached to the wrong paragraph. In this case,
it was moving the text-body frame into the footer.

So make a stack of these things, so that each
paragraph can keep track of it's own setting.

RTF can have endParagraph without startParagraph.
Although that doesn't seem to apply
in this DOCX-only context, just to be safe
I'm assuming that it could in theory happen
as well with a DOCX, and so never assume
that the stack exists.

Based on a code read, (and then a
confirming unit test,) things seem to be
complicated by multi-levels of textboxes
that need to be squished.

The for loop with a changing upper end
really threw me for a loop, so I'm
clearly documenting that.

Change-Id: I1060736c0a2174af125d853ff7d72265e000c8de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107516
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/sw/source/filter/ww8/docxattributeoutput.hxx b/sw/source/filter/ww8/docxattributeoutput.hxx
index 349cab0cb310..cfc6eae89f12 100644
--- a/sw/source/filter/ww8/docxattributeoutput.hxx
+++ b/sw/source/filter/ww8/docxattributeoutput.hxx
@@ -854,7 +854,7 @@ private:
     // This paragraph must end with page break
     bool m_bPageBreakAfter = false;
 
-    std::vector<ww8::Frame> m_aFramesOfParagraph;
+    std::stack< std::vector<ww8::Frame> > m_aFramesOfParagraph;
     o3tl::sorted_vector<const SwFrameFormat*> m_aFloatingTablesOfParagraph;
     sal_Int32 m_nTextFrameLevel;