Bug 134951 - FILESAVE DOCX: Additional (spurious) footnote is added on export
Summary: FILESAVE DOCX: Additional (spurious) footnote is added on export
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Justin L
Whiteboard: target:7.2.0
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Footnote-Endnote
  Show dependency treegraph
Reported: 2020-07-19 11:00 UTC by Telesto
Modified: 2021-04-16 06:41 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Example file (235.91 KB, application/vnd.oasis.opendocument.text)
2020-07-19 11:00 UTC, Telesto
tdf134951_patch.diff: working patch with debugging (3.97 KB, patch)
2020-08-06 12:00 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-07-19 11:00:41 UTC
FILESAVE DOCX/DOC: Distribution of bullet-ed items changes  

Steps to Reproduce:
1. Open the attached file
2. Save as DOCX
3. File reload

Actual Results:
Red highlighted item moves to first page from second

Expected Results:
Same as ODT

Reproducible: Always

User Profile Reset: No

Additional Info:
Found in

And in
Build ID: 5ad7b2889021c491af62f7930a4b1cb631392f16
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: old; 
Locale: nl-NL (nl_NL); Calc: group

Different look in

Maybe related to/caused by bug 134949
Comment 1 Telesto 2020-07-19 11:00:53 UTC
Created attachment 163266 [details]
Example file
Comment 2 Xisco Faulí 2020-08-03 14:27:36 UTC
yes, it moves to the first page, what's the problem ?
Comment 3 Telesto 2020-08-03 19:03:31 UTC
(In reply to Xisco Faulí from comment #2)
> yes, it moves to the first page, what's the problem ?

No clue, not sure how much comp-ability DOCX developers want to achieve; As it does change the page layout. Especially if you're working in LibreOffice & save it to DOCX, expecting it to be the same thing on re-opening

So if this can avoided, I personally would prefer it for interoperability reasons. But no clue what's reasonable here.
Comment 4 Telesto 2020-08-03 19:04:59 UTC
An developer opinion needed.. any worth having this.. or can it be closed not a bug
Comment 5 Justin L 2020-08-03 19:51:09 UTC
The real problem here is the footnotes - there is an extra footnote inserted in DOC/DOCX. Also, things are confused, because footnote 12 and 13 are shown on the next page.

This entry has two footnotes attached to it in the docx version.
Fahri Korutürk(1973-1980) (10 and 11).

This is definitely an export problem - extra footnote also seen in Word 2003.
Comment 6 Telesto 2020-08-03 20:23:27 UTC Comment hidden (off-topic)
Comment 7 Telesto 2020-08-03 20:28:11 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2020-08-04 04:20:12 UTC Comment hidden (obsolete, spam)
Comment 9 Justin L 2020-08-04 06:30:32 UTC
linux bibisect44max 4.4 commit 54d52f6062dffaa930f008c9e1655132dd395c83
    commit 80fd9fb7209cfd5c0622ee99d59e42e6db32f021
    Author:     Umesh Kadam <umesh.kadam@synerzip.com>
    CommitDate: Thu May 22 02:31:53 2014 -0500
        tdf#78333 : SdtContent and a Shape overlapping causes corruption

- Normally if there is a case where text/shape is overlapped with (another)
shape then LO used to write the text and the AlternateContent in the same run.
- This is supported in MSO and there is no visual difference.
- But in case if the SdtContent(with text) is overlapped with the Shape then LO
processes sdtContent as a text and ends up putting the alternateContent and the text in a single run. Ultimately it includes the entire run in a SdtContent,
which is incorrect.
- The fix checks for the aforementioned scenario and puts them in a different run
and also restricts the sdtContent being written in an invalid AlternateContent.
Comment 11 Justin L 2020-08-06 10:03:06 UTC
Here are some follow-up commits to the regressive one that might be useful:

commit fe5b3c3357d9e613a0be53ec1e5546a59e21cea0
Author: Ravindra Vidhate on Wed Jun 11 16:38:17 2014 +0530
    fdo#79915:Text Data Lost after exporting through LO

commit 570775d352c1465763bb9db974c4503245652d79
Author: Rohit Deshmukh on Fri Jul 11 15:18:17 2014 +0530
    fd0#80997: Fix for text missing which is behind textbox in RT.

commit eae5d8de6dde0ea4dd1494b0e1f036789b7c6220
Author: Miklos Vajna on Tue Sep 23 17:48:40 2014 +0200
    DOCX export: fix duplicated OLE objects
Comment 12 Justin L 2020-08-06 12:00:17 UTC
Created attachment 164001 [details]
tdf134951_patch.diff: working patch with debugging

There probably is something more fundamentally wrong happening here. Like, why would a new paragraph be started without a new character set, and when it is finished, why wouldn't they be popped, and then just continue with the existing pair on the stack?

So I'm not planning to submit this as a patch. However, I think it would be fine to do if this bug really needs fixing.
Comment 13 Justin L 2020-08-06 12:04:21 UTC
Removed references to DOC since other bugs suggest that DOC format should completely avoid this bPostponeWritingText craziness.
Comment 14 Justin L 2021-04-15 13:53:29 UTC
(In reply to Justin L from comment #13)
> Removed references to DOC since other bugs suggest that DOC format should
> completely avoid this bPostponeWritingText craziness.
In bug 134948, bPostponeWritingText was isolated to only affect DOCX. Unfortunately, unit tests still fail if we eliminate it altogether.
Comment 15 Commit Notification 2021-04-16 06:27:43 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#134951 docxexport: stop duplicating stuff in postponed text

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://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.
Comment 16 Justin L 2021-04-16 06:41:34 UTC
So, I'm going to mark this as fixed based on the modified subject, and comment 5.

The part about all 12 footnotes not showing up on the first page is still there, but even on the original ODT, if I move the picture anchor up just one paragraph then the same thing happens (for no apparent reason). And moving it down one again doesn't "fix" it either - it needs to bump down all the way to footnote 12's paragraph before the layout changes again.

This layout issue probably is not worth reporting as a bug until something more concrete can be identified as causing the problem.