Created attachment 85639 [details] RTF document that will show the problems after being resaved as RTF Saving the attached RTF file again as RTF adds 1 section that isn't there before and also adds lots of page breaks almost every paragraph gets a page break after it. Besides that some of the endnotes get the page header text added.
Not reproducible under Crunchbang 11 running TDF/LO v4.1.0.4, so possibly a regression introduced since this release.
@Jacob which O/S do you use? you reported bug in 4.1.1.2, was it there in previous releases as well?
My OS is Windows 7 Home Premium 64 bits. I was previously using I think 4.0.3 (not 100% sure about the 3) and upgraded to see if it fixed another bug I encountered in that version. The bug I'm reporting here was not in 4.0.3 and also not in the version I reverted to now: Version 4.0.5.2 .5.2 (Build-id: 5464147a081647a250913f19c0715bca595af2f)
basically the 4.0.x version are unaffected by the bug you reported here in 4.1.1.2, right? so you experienced a regression of the 4.1.x branch, isn't it?
regression confirmed on my Win7 64bit PC with 4.1.0.4 and 4.1.1.2 releases and with 4.2.0.0 master build Sept.10. resaving the test .rtf file with those LibO versions messes it up, while resaving works fine in 4.0.5. I add Miklos Vaina (RTF expert) to CC list, maybe he can help.
Can't reproduce on Linux with 4.1.0 (Version: 4.1.0.4; Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28). After import: 11 pages, after save + reload: 11 pages as well, so I don't see any additional page breaks. Could you please provide two screenshots: old (good) and new (bad)? Thanks.
Created attachment 86315 [details] screenshot screenshot of changes of RTF document after saving and reloading it in 4.1.1.
maybe another Window specific bug?
I have conducted a bit more testing here under several platforms with a few different versions of LO. All these combinations work OK for both open and re-save to RTF: - Win7HP LOv4.0.3.3 Build: 0eaa50a932c8f2199a615e1eb30f7ac74279539 - MacOS10.6.8 LOv4.0.3.3 Build: 0eaa50a932c8f2199a615e1eb30f7ac74279539 - Ubuntu10.04 LOv4.1.0.4 Build: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 The version of LO I tested with in comment #1 is the same build as that above for Ubuntu and that reported in comment #6. I then removed v4.0.3.3 from Win7HP and installed: - Win7HP LOv4.1.2.2 Build: 281b75f427729060b6446ddb3777b32f957a8fb This version opens even the original RTF in a manner that places additional carriage returns between each endnote as shown in the screenshot in comment #7. The document is still 11 pages in length at this point. Saving the RTF though causes the file to expand to 56 pages with all sorts of breaks and additional carriage returns being inserted, just as described in the original report. I will upload a ZIP of my various test files later today for others. Would like to test with v4.1.2.2 under GNU/Linux and MacOS first.
Created attachment 86498 [details] Re-saves of the original RTF under various platform/LO combinations. Tested further under these platforms/versions with OK results for both opening and re-save to RTF: - MacOS10.6.8 LOv4.1.1.2 Build: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 - MacOS10.6.8 LOv4.1.2.2 Build: 281b75f427729060b6446ddb3777b32f957a8fb - Crunchbang11 LOv4.1.2.2 Build: 281b75f427729060b6446ddb3777b32f957a8fb It would appear to be a problem restricted to the Windows build as suggested in comment #8. The files in the attached ZIP should be self-explanatory. The suffix indicates the platform+LO used to save the file. I have also included a couple of screenshots for LOv4122 under Win7HP to show what I am seeing. The full extent of the problem though can really only seen by opening "SE 08 Win7HP LOv4122.rtf".
The screenshots from comment #7 en comment #10 are exactly what I'm seeing too before/after saving with LO 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 Showing and resaving in 4.0.5.2 shows everything as it should be. All tested on Win7-64.
I reproduce the issue with LibreOffice 4.3.3 on Debian, but I can not reproduce it with 4.4.0.0beta1 on Debian nor on Windows 7. As far as I do not know which patch solves the problem, I set bug status to RESOLVED WORKSFORME. Please, set it to UNCONFIRMED if you can reproduce the issue with LibreOffice 4.4.0.0.-beta1 or later.
Migrating Whiteboard tags to Keywords: (filter:rtf) [NinjaEdit]
fix by commit 7146d8bcd96f844dc0239a5b29a6b36c3cb5a2cc Author: Miklos Vajna CommitDate: Mon Jul 28 17:06:44 2014 +0200 MSWordExportBase::OutputSectionBreaks: avoid fake section breaks Regression from ee9f23bb94b4c2c8c4db6466ecca272a092e9492 (docx export: invalid sectPr added at the beginning of the doc, 2013-01-10), the problem was that we even tried to generate section breaks at places where the two page styles are in practice the same.