Created attachment 147982 [details] Sample file Steps to reproduce: 1. Open attached document 2. Save it as .RTF 3. Open the new document -> The document contains 3 sections. The original one only one. The new sections make the document layout to look different. See the empty lines on top Reproduced in Version: 6.3.0.0.alpha0+ Build ID: 49c61f660d05ab13140d4349a0b3f6efba742022 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded [Bug found by office-interoperability-tools]
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=3955e5efc225b184b9507db94c226c031a602168 author Justin Luth <justin.luth@collabora.com> 2018-10-18 11:44:11 +0300 committer Justin Luth <justin_luth@sil.org> 2018-10-31 05:00:21 +0100 commit 3955e5efc225b184b9507db94c226c031a602168 (patch) tree 7154c64e3f0518d583e01528fb55ff5acb62b289 parent dc2509bca4f503c11cdde16779363a5aae67185f (diff) writerfilter: implement formprot Bisected with: bibisect-linux64-6.2 Adding Cc: to Justin Luth
Created attachment 148058 [details] rtfSections.odt: bibisect43all - sections accumulate in RTF since OOo Well, this hardly counts as a regression, since the mere existence of any section causes them to multiply in RTFs. So you must have millions of examples of that happening for a long time. The only difference this patch makes is to add the first section to a file that previously didn't have any section - a fairly necessary thing to enable section-only features.
proposed fix at https://gerrit.libreoffice.org/65974
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f18300642c3e962d7c0c6d13daad1676b877b30b%5E%21 tdf#122345 filter/ww8 export: no fake section at end of document It will be available in 6.3.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/5deec1c02ca1f2df30b0c33d516d3aa10285fb3b%5E%21 tdf#122456 filter/ww8 export: no fake section at end of document It will be available in 6.2.1. 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.
Created attachment 149655 [details] A DOC that cannot be opened by Word 2016-2019 Heh, wrt "but it also affects docx and doc (without noticable benefit or harm" part of the commit message - there *is* noticeable harm at least for DOC binary format, since such DOC documents are *not* opened by Word 2016 and 2019 (but open fine in Word 2010; see https://forumooo.ru/index.php/topic,7552 - russian). So the commits by Justin fix also real problem with DOC. Opening and re-saving attachment with 6.2.1 makes it openable with Word 2016+ again. Thank you Justin!
(In reply to Mike Kaganski from comment #6) > Created attachment 149655 [details] > A DOC that cannot be opened by Word 2016-2019 > > Heh, wrt "but it also affects docx and doc (without noticable benefit or > harm" part of the commit message - there *is* noticeable harm at least for > DOC binary format, since such DOC documents are *not* opened by Word 2016 > and 2019 (but open fine in Word 2010; see > https://forumooo.ru/index.php/topic,7552 - russian). So the commits by > Justin fix also real problem with DOC. > > Opening and re-saving attachment with 6.2.1 makes it openable with Word > 2016+ again. Thank you Justin! Those are fantastic news!! Initial problem verified in Version: 6.3.0.0.alpha0+ Build ID: 8aa579830b20072af8d6e149d6b279362fe98b91 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Justin Luth, thanks for the fix!