Description: 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 Actual Results: Header is blank Expected Results: There is a text box in the header Reproducible: Always User Profile Reset: No Additional Info: 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
Reproducible with Version: 6.1.0.0.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 <vmiklos@collabora.co.uk> 2014-08-18 15:14:31 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> 2014-08-18 15:51:16 +0200 commit f6b681a1360d953ec7a9f2f4f843c0d76d478c2a (patch) tree 0a79b7d29081cf342643e3492bd3fd42ee52f23c 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 are invoked. Fix the problem by adjusting these methods to writeDMLAndVMLDrawing(), so that they also set m_bDMLAndVMLDrawingOpen to true during the TextBox export. 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 commit 70f49dc6927f3321e764174bd8050acaff63be32 Author: Pallavi Jadhav <pallavi.jadhav@synerzip.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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=853350787df9a8d92c269ef1b6e764863e74ec2a 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: http://wiki.documentfoundation.org/Testing_Daily_Builds 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 https://bugs.documentfoundation.org/show_bug.cgi?id=118242
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 > > https://bugs.documentfoundation.org/show_bug.cgi?id=118242 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