Opening the file "Frames.odt" in writer and exporting it to docx removes the text box in the header. To see the effect, the file has to be reloeaded.
Steps to Reproduce:
1. Open the odt file
2. Export to docx
3. Reopen the docx file
Header is blank
There is a text box in the header
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Created attachment 142277 [details]
sample odt file
Created attachment 142278 [details]
docx export of the odt file
Version: 188.8.131.52.beta1 (x64)
Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0
CPU threads: 4; OS: Windows 10.0; UI render: GL;
Locale: de-DE (de_DE); Calc: CL
Created attachment 142371 [details]
minimal file causing the bug
Created attachment 142372 [details]
docx export of minimal file
The bug is independent of the text box in the header. I created a minimal file with text in the header.
It seems to be caused by one flying text frame which contains a "section". Removing the "section" in the frame (or the whole frame) resolves the bug.
So, in docx export the "section" removes the header ...
Regression introduced by:
author Miklos Vajna <email@example.com> 2014-08-18 15:14:31 +0200
committer Miklos Vajna <firstname.lastname@example.org> 2014-08-18 15:51:16 +0200
commit f6b681a1360d953ec7a9f2f4f843c0d76d478c2a (patch)
parent aa1d3d5eeaa795f6b913bbcd55bd31dc6802a4fe (diff)
DOCX export: don't forget to close SDT elements inside the TextBoxes of shapes
A usual problem with SDT is that in case it should end after the last
paragrah of a container, there is no "next" paragraph that could have
the relevant "EndSdtBefore" property. This is usually handled by closing
the SDT tag before the container is closed.
The problem here was that DocxAttributeOutput::WriteSdtBlock() did not
notify DocxSdrExport about opening the SDT, as it thought there is no
draw export in progress. This is because in case of "shape with a
TextBox", the common writeDMLAndVMLDrawing() method is not called,
instead the separate writeDMLTextFrame() and writeVMLTextFrame() methods
Fix the problem by adjusting these methods to writeDMLAndVMLDrawing(),
so that they also set m_bDMLAndVMLDrawingOpen to true during the TextBox
Bisected with: bibisect-44max
Adding Cc: to Miklos Vajna
Thanks Xisco for finding that regression! I can confirm it causes the bug.
It is also connected to
Author: Pallavi Jadhav <email@example.com>
Date: Thu May 22 13:31:48 2014 +0530
fdo#78882: DOCX: File gets corrupt after Roundtrip
short cutting / removing the
if( !m_rExport.SdrExporter().IsDMLAndVMLDrawingOpen() )
line from the commit affects the issue. But no idea how the information flow is organized here. But hopefully the info helps :)
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":
tdf#117805 DOCX export: fix lost header with at-page anchored frames
It will be available in 6.2.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
See the commit message details, this is meant to address the regression part; I suggest to open a follow-up non-regression bug to improve this further so that the DOCX export result would be on part with the DOC export result.
Thanks Miklos, I confirm that the header is back (albeit at the wrong position). Is there a chance to get this backported to 6.1 or even 6.0?
The follow-up non-regression bug is
Patrick noted that this is a minefield: now that I restored the old behavior this also means that the DOCX output for this case is well-formed, but not valid -> Word may or may not open the resulting document.
I *think* it would be wise to backport this fix only when bug 118242 is also fixed. Patrick, what is your opinion?
(In reply to Oliver Sander from comment #12)
> Thanks Miklos, I confirm that the header is back (albeit at the wrong
> position). Is there a chance to get this backported to 6.1 or even 6.0?
> The follow-up non-regression bug is
Thanks for checking the fix. Setting to VERIFIED
(In reply to Miklos Vajna from comment #13)
> Patrick noted that this is a minefield: now that I restored the old behavior
> this also means that the DOCX output for this case is well-formed, but not
> valid -> Word may or may not open the resulting document.
> I *think* it would be wise to backport this fix only when bug 118242 is also
> fixed. Patrick, what is your opinion?
I agree with you. Now we have some time until the 6.2 release to fix the follow-up bug https://bugs.documentfoundation.org/show_bug.cgi?id=118242