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
Created attachment 165730 [details] Example file
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
Please, add a screenshot of the problem
Created attachment 166326 [details] Screenshot
[Automated Action] NeedInfo-To-Unconfirmed
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.
(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.
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
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.
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
(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?
(In reply to Telesto from comment #11) > Are we talking about the source document (the ODT), DOCX or even both? DOCX
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)
Created attachment 167982 [details] Sampleshort3D2.odt: severely minimized version showing large footer with image.
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
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.
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!
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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/b850105570d0e99644ff1ad5d6d0f09734db7952 Revert "tdf#136929 docx export: keep frame with paragraph" It will be available in 7.1.3. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-1-2": https://git.libreoffice.org/core/commit/b2c08ff1e0bc525ed7225c0fa4749c0240d9a5ad Revert "tdf#136929 docx export: keep frame with paragraph" It will be available in 7.1.2. 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.