Bug 117805 - DOCX: section in frame removes header in docx export
Summary: DOCX: section in frame removes header in docx export
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:6.2.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Frames DOCX-Header-Footer
  Show dependency treegraph
 
Reported: 2018-05-25 16:15 UTC by Patrick Jaap
Modified: 2018-06-21 09:46 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
sample odt file (32.00 KB, application/vnd.oasis.opendocument.text)
2018-05-25 16:16 UTC, Patrick Jaap
Details
docx export of the odt file (9.44 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-05-25 16:16 UTC, Patrick Jaap
Details
minimal file causing the bug (14.55 KB, application/vnd.oasis.opendocument.text)
2018-05-29 09:41 UTC, Patrick Jaap
Details
docx export of minimal file (8.43 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-05-29 09:42 UTC, Patrick Jaap
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Jaap 2018-05-25 16:15:56 UTC
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
Comment 1 Patrick Jaap 2018-05-25 16:16:22 UTC
Created attachment 142277 [details]
sample odt file
Comment 2 Patrick Jaap 2018-05-25 16:16:46 UTC
Created attachment 142278 [details]
docx export of the odt file
Comment 3 Dieter Praas 2018-05-25 17:50:49 UTC
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
Comment 4 Patrick Jaap 2018-05-29 09:41:57 UTC
Created attachment 142371 [details]
minimal file causing the bug
Comment 5 Patrick Jaap 2018-05-29 09:42:32 UTC
Created attachment 142372 [details]
docx export of minimal file
Comment 6 Patrick Jaap 2018-05-29 09:45:10 UTC
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 ...
Comment 7 Xisco Faulí 2018-05-31 15:30:02 UTC
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
Comment 8 Patrick Jaap 2018-06-04 09:48:42 UTC
Thanks Xisco for finding that regression! I can confirm it causes the bug.
Comment 9 Patrick Jaap 2018-06-04 12:14:15 UTC
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 :)
Comment 10 Commit Notification 2018-06-19 07:03:50 UTC
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.
Comment 11 Miklos Vajna 2018-06-19 07:05:33 UTC
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.
Comment 12 Oliver Sander 2018-06-20 07:03:04 UTC
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
Comment 13 Miklos Vajna 2018-06-20 12:41:14 UTC
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?
Comment 14 Xisco Faulí 2018-06-20 15:48:52 UTC
(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
Comment 15 Patrick Jaap 2018-06-21 09:46:36 UTC
(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