Created attachment 138276 [details] Comparison before and after the RT Steps to reproduce: 1. Open attachment 107303 [details] from bug 84645 2. Save it as .RTF 3. Open the new file Observed behaviour: second column is displayed right after the first column instead of next to it. see screenshot Reproduced in Version: 6.1.0.0.alpha0+ Build ID: 495ac1bc97f3deea8e13cb1a2b9f59d087873c3f CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: en-US (ca_ES.UTF-8); Calc: group threaded [Bug found by office-interoperability-tools]
Regression introduced by: author Justin Luth <justin_luth@sil.org> 2017-11-07 09:29:30 +0300 committer Justin Luth <justin_luth@sil.org> 2017-11-09 05:40:08 +0100 commit afc96d263959d10e457b54a574f0829d20e99df4 (patch) tree 66f0aa20534e80f2ee53412436eb2c3c450fc64a parent 6502ebb0e977f6bea305e5e1598520a6b8b9f770 (diff) tdf#112352 ooxmlimport: ALWAYS treat 1st nextpage w/cols as cont fix 5.4 regression from 4605bd46984125a99b0e993b71efa6edb411699f. When there are columns, if a nextpage section doesn't contain any other "page style" details we treat it as a continuous break, If we don't, the column info becomes part of the style itself, and not just a section property. However, the very first section is troublesome - by definition it DOES contain page style details, and so if the document starts with columns, the default style would gain the column attribute. Usually that results in a mess, so lets make sure that we avoid that also in the case where headers/footers are defined. Bisected with: bibisect-linux64-6.0 Adding Cc: to Justin Luth
Attachment 81700 [details] from bug 66373 is also affected by the same problem.
This is not a true regression - the RTF just happened to look better starting in 5.4. The original file has a section with 2 columns in it, and a page-style with one column. The round-tripped file has no sections, but a default page style with 2 columns, which is completely incorrect even though it visually looks accurate. bibisect43all-3.6: also round-trips as 2 columns page-style bibisect42all-4.2: round-trips adding a section each time, and only one column. bibisect43all-4.3: round-trips with section/2 columns (but with an extra CR on line 1, and an extra, empty section added for each round-trip.) bibisect44max: round-trips as no sections, single column -columns/section lost in c4a5f8c1afd42acb52d0ae9b4d6f42f3e87364d5 -the extra initial CR is fixed by 75c5679a96437caa6041d2550562f2a4db80d586 LO 4.3 was a complete mess, with this document doing all kinds of different things at various stages, and lots of "git bisect skip" failures. In the case (like this document) where there is only one section, we might be able to get away with simulating that by defining the columns in the page style instead. writerfilter/source/dmapper/PropertyMap.cxx: const bool bTreatAsContinuous = ... && !rDM_Impl.GetIsLastSectionGroup()
Dear Xisco Faulí, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Версия: 6.5.0.0.alpha0+ (x64) ID сборки: 32dcf3f0fdafcf44457842a8aa4f54d30d856ca9 Потоков ЦП: 4; ОС:Windows 10.0 Build 17763; Отрисовка ИП: GL; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded
Dear Xisco Faulí, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Issue fixed by author Justin Luth <justin.luth@collabora.com> 2020-12-10 16:48:06 +0300 committer Miklos Vajna <vmiklos@collabora.com> 2020-12-15 09:28:43 +0100 commit 8787a45f9cbb5dce61b20817ef0e549b5a227a95 (patch) tree 533944cbbcc2373e7aa0e2b00e4b468b5458dcd8 parent 2b0333d09526d85ea70ab4dfdba2c3593724c80d (diff) tdf#118711 writerfilter: don't hardcode default page description
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/da4b873245b9f5a096048e2370041c6278ebaf4a tdf#114309: sw_rtfexport: Add unittest It will be available in 7.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.