Bug 136929 - FILESAVE DOCX: Large footer when image moved from text body into footer
Summary: FILESAVE DOCX: Large footer when image moved from text body into footer
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.2.0 target:7.1.0.0.beta2
Keywords:
Depends on:
Blocks: DOCX-Page DOCX-Section
  Show dependency treegraph
 
Reported: 2020-09-21 12:01 UTC by Telesto
Modified: 2020-12-14 10:24 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (1.14 MB, application/vnd.oasis.opendocument.text)
2020-09-21 12:01 UTC, Telesto
Details
Screenshot (435.25 KB, image/jpeg)
2020-10-12 20:07 UTC, Telesto
Details
Sampleshort3D2.odt: severely minimized version showing large footer with image. (175.14 KB, application/vnd.oasis.opendocument.text)
2020-12-08 16:36 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-09-21 12:01:12 UTC
Description:
Large footer introduced in after filesave DOCX

Steps to Reproduce:
1. Open the attached file
2. Save as DOCX
3. File reload 
4. Look page 24/page 26 (Footer Converted 4) style

Actual Results:
Large footer

Expected Results:
Not present in source file


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: abcc4eb907661e07ad850ccce7eb06f129da4286
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-09-21 12:01:32 UTC
Created attachment 165730 [details]
Example file
Comment 2 Telesto 2020-09-23 19:31:55 UTC
Broken in
6.4

fine in
Version: 6.2.0.0.alpha0+
Build ID: 9d754a59154c40235c240bb0e7f47a2006fa85bd
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 3 Xisco Faulí 2020-10-12 17:50:02 UTC
Please, add a screenshot of the problem
Comment 4 Telesto 2020-10-12 20:07:25 UTC
Created attachment 166326 [details]
Screenshot
Comment 5 QA Administrators 2020-10-13 04:48:13 UTC Comment hidden (obsolete)
Comment 6 Timur 2020-10-19 12:10:10 UTC
I asked Telesto few times, upon seeing they are not well described, not to set bibisectRequest in unconfirmed bugs, and again. 
First, when setting bibisectRequest it should be clear in which version  regression came, so to know which repo to choose. Here, not clear. 
When reporting a bug, it's bad practice to just upload large file, there should be a minimal size sample. 
But here, there's no simple bug, nor is it as described "Large footer". It's text box in footer.
But I don't see this ever fine, seen if not concentrated to footer but to image position. Sometimes it's double, sometimes in the footer.
I set Needinfo for minimal sample and history of changes, to see if this was ever fine and why image is wrong in DOCX.
Comment 7 Telesto 2020-10-19 14:35:46 UTC
(In reply to Timur from comment #6)
> I asked Telesto few times, upon seeing they are not well described, not to
> set bibisectRequest in unconfirmed bugs, and again. 

-> I didn't at first, next it requested (back in they day: Xisc0), now I supposed to refrain.. 

> First, when setting bibisectRequest it should be clear in which version 
> regression came, so to know which repo to choose. Here, not clear. 

-> Comment 2 for the range. 

> When reporting a bug, it's bad practice to just upload large file, there
> should be a minimal size sample. 
> But here, there's no simple bug, nor is it as described "Large footer". It's
> text box in footer.

-> It's text box (or specific text frame + image (called shape24)
And it appears to be figure 21 on page 23 being all over the place

> But I don't see this ever fine, seen if not concentrated to footer but to
> image position. Sometimes it's double, sometimes in the footer.

-> Gibberish to me. Please rephrase. If conclusion is me being wrong and it also broken in 6.2 please say so.

> I set Needinfo for minimal sample and history of changes, to see if this was
> ever fine and why image is wrong in DOCX.

-> I'm not a trim down specialist; I did trim it down already (from 250 pages) And the last time I more I stopped working. The size is pretty manageable, even for a bibisect.

They answer "why" you find out by bibisecting. Which actually still not 'answer' but only a pointer. And it was exported 'fine'; comment 2.
Comment 8 NISZ LibreOffice Team 2020-12-07 12:46:16 UTC
This started in 6.3 with:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=5f0cfbbe1840428b07c1ba807ca8123df60bd8a0

author	Justin Luth <justin_luth@sil.org>	2018-12-11 15:55:26 +0300
committer	Miklos Vajna <vmiklos@collabora.com>	2018-12-14 14:08:35 +0100

sw export: restore ww8 FormatBreak() to pre-2014 logic

Adding CC to: Justin Luth
Comment 9 Justin L 2020-12-07 14:55:38 UTC
I can't even scroll down to the bottom of the document in development compile - it crashes trying to access string position [0] when the text length is zero.
sw/source/core/txtnode/fntcache.cxx:2014.
Comment 10 Justin L 2020-12-08 13:22:15 UTC
Ahh good. This was not marked as a regression. It seems fairly clear to me that this is likely just exposing something else. But there is SO MUCH wrong with this document, that it is hard to make any robust conclusions.

My commit should only be affecting where LibreOffice 2 does a page-after break. At that time, the footnote-containing-content switched from the even page to the odd page. (I don't know why - and it hardly seems relevant.)

The reason the footnote is huge is because it contains a "caption" frame for the last picture in the document. Somehow that managed to find its way into the footnote on every odd page. Indeed, the entire picture itself was part of the footnote until LO 7.1's author Attila Bakos on 2020-08-21 23:48:33 +0200
commit	b6850bbe95418ecfde404be1696548f18d200c9b
tdf#106153 sw compatibility: fix textboxes exceeding the page
Comment 11 Telesto 2020-12-08 16:18:27 UTC
(In reply to Justin L from comment #10)
> But there is SO MUCH wrong with this document, that it is hard to make any robust conclusions.

Are we talking about the source document (the ODT), DOCX or even both?
Comment 12 Justin L 2020-12-08 16:25:42 UTC
(In reply to Telesto from comment #11)
> Are we talking about the source document (the ODT), DOCX or even both?
DOCX
Comment 13 Telesto 2020-12-08 16:32:10 UTC
FWIW: track & changes is involved. That's whole different can of worms :P. There quite a bunch of issue (or should I say countless) flying around since the 6.2 refactor (M. Stahl). Which obviously also appear in DOCX format...

So not even sure if what you're seeing being DOCX issues or only redlining. I would even attribute the wrong export to M. Stahl/ track changes (until proven otherwise)
Comment 14 Justin L 2020-12-08 16:36:01 UTC
Created attachment 167982 [details]
Sampleshort3D2.odt: severely minimized version showing large footer with image.
Comment 15 Justin L 2020-12-10 09:58:48 UTC
Non-problem: Missing odd footer contents

The reason that the odd footer is not showing text is because of the strange design. Instead of being "right" aligned, there is a tabstop at 17cm. Removing the tabstop or the tab shows the (read-only) field.

A fix for the image moving into the footer is proposed at
http://gerrit.libreoffice.org/c/core/+/107516
Comment 16 Commit Notification 2020-12-11 10:10:51 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3fd156419654ba5e2f248357a2eed5eeaad04548

tdf#136929 docx export: keep frame with paragraph

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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Xisco Faulí 2020-12-14 10:22:57 UTC
Verified in

Version: 7.2.0.0.alpha0+
Build ID: 9a2a4bc5ed340ba187c8e27db5c8477c990c93af
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Before the commit, the resulting document has 30 pages, after it, 24 pages, same as the odt file.

@Justin Luth, thanks for fixing this issue!
Comment 18 Commit Notification 2020-12-14 10:24:36 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/7d90b50285f294a3c9cce0b22399fefe3ab46ee5

tdf#136929 docx export: keep frame with paragraph

It will be available in 7.1.0.0.beta2.

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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.