Created attachment 133195 [details] example with text object The text object has no line in the odt, but has a line when exported to RTF.
Hi Christian, Confirmed with LO 5.4.0.0.alpha1+ Build ID: 0025fc13d805751f8eeb14febbdd0033e0a6d91e CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-04_05:21:32 Locale: fr-FR (fr_FR); Calc: CL and LO 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 but not with LO 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24) Thanks to provide also the OS where you found this issue.
bibisect-41max There are only 'skip'ped commits left to test. The first bad commit could be any of: 39673b93cb08c61749d3371dc2e9c0c54156e61c source-hash-adcae497ce48a6ff6e994817b17840842faa8732 commit adcae497ce48a6ff6e994817b17840842faa8732 Author: Noel Grandin <noel@peralex.com> AuthorDate: Fri Apr 12 16:46:32 2013 +0200 Commit: Thomas Arnhold <thomas@arnhold.org> CommitDate: Fri Apr 12 15:38:12 2013 +0000 1ce886ae9a67171ff46ad30c42d0a311aebef4df source-hash-120922361a5928ea4437ffe253ce209abd7060b0 commit 120922361a5928ea4437ffe253ce209abd7060b0 Author: Jan Holesovsky <kendy@suse.cz> AuthorDate: Fri Apr 12 17:02:17 2013 +0200 Commit: Jan Holesovsky <kendy@suse.cz> CommitDate: Fri Apr 12 17:10:53 2013 +0200 i#23187: Fix crash of the document. The mbLayoutInProgress bool was effectively unused - only set and reset, but the only place that was checking for that was in lcl_RecalcRow(), again, only to set and reset it. Worse - with the document from i#23187, the mbLayoutInProgress was set / reset on a page already disposed in SwFrm::InsertPage() which was causing the 3c53704880654e9b6626fc5babaf47ab31e813d5 source-hash-f3c4b5606d4a697efbe3041530fc7f7d5a3a47b0 commit f3c4b5606d4a697efbe3041530fc7f7d5a3a47b0 Author: Michael Meeks <michael.meeks@suse.com> AuthorDate: Fri Apr 12 19:03:15 2013 +0300 Commit: Tor Lillqvist <tml@iki.fi> CommitDate: Fri Apr 12 19:03:49 2013 +0300 Add more components 7d3a0b4604a1c8f8a2c69d2593da60f62e1066e0 source-hash-d53dd70b15f0e3f7c8a05a93f8fcd70e1147c1f7 commit d53dd70b15f0e3f7c8a05a93f8fcd70e1147c1f7 Author: Miklos Vajna <vmiklos@suse.cz> AuthorDate: Fri Apr 12 15:09:12 2013 +0200 Commit: Miklos Vajna <vmiklos@suse.cz> CommitDate: Fri Apr 12 16:33:07 2013 +0200 sw: rework RTF export of text frames Export these as new-style frames. Not counting future possibilities, this commit finally fixes the following problems: - borders: spacing to contents wasn't exported at all - wrap: top/bottom and left/right spacing exported even in case they do not equal cf87bf0da430de04e07b8106988d5d5c0d2fd915 source-hash-9de73714775833f3ec7e7508d5fddcc8e4f19aed commit 9de73714775833f3ec7e7508d5fddcc8e4f19aed Author: Jan Holesovsky <kendy@suse.cz> AuthorDate: Fri Apr 12 18:46:17 2013 +0200 Commit: Jan Holesovsky <kendy@suse.cz> CommitDate: Fri Apr 12 18:48:44 2013 +0200 i#116001: Decrementing the iterator while comparing is not a good idea here. When it is begin(), it will get decremented regardless the result of the test, but probably affects only the dbgutil build. 006fb997f37fa41c3529804047083d5231fcdedb source-hash-da16b278eeb5b3e2994de68e49d88a64fdb7ac5b commit da16b278eeb5b3e2994de68e49d88a64fdb7ac5b Author: Miklos Vajna <vmiklos@suse.cz> AuthorDate: Fri Apr 12 16:29:25 2013 +0200 Commit: Miklos Vajna <vmiklos@suse.cz> CommitDate: Fri Apr 12 16:33:07 2013 +0200 RTF import: initial handling of posrelh and posrelv shape properties Change-Id: Id576d6df4b7a6144507e5f8230ac62a953b5c050 ab37c86e122eff7522cdbe85d51c6a5ecfd0f3d7 source-hash-db8786e34b1a451f0e6969681079f701627de6f9 commit db8786e34b1a451f0e6969681079f701627de6f9 Author: Tor Lillqvist <tml@iki.fi> AuthorDate: Fri Apr 12 19:47:14 2013 +0300 Commit: Tor Lillqvist <tml@iki.fi> CommitDate: Fri Apr 12 19:55:36 2013 +0300 The silly toolsdll.cxx was the same for unx and win d8696d9dc384319390767c5a5baad0ec95bab35b source-hash-1f39925c4cafc52009f4505fd3e4b6843f6e7944 Bibisect: This commit covers the following source commit(s) which failed to build a6e1f214c9c8c338da7cd216884e45e234e64669 694ac8155517a88e7317170b189f9d5fabc270b0 ffa651bd4f4476bf2d734c6931af271e58acb88b 9fb856ce844f2a4e794687c00ad6f0f75ef223c1 0557453a35863310f34e6c10facbac63bc89837d f1bdd56b4f983282619a4c1fdc4222f25215ca46 1799937b9ec2584c6e6c783ede5f22d72a1f44f9 commit 1f39925c4cafc52009f4505fd3e4b6843f6e7944 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Fri Apr 12 15:11:17 2013 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Fri Apr 12 15:11:58 2013 +0100 fix build, "touch" headers only on !HAVE_FEATURE_DESKTOP platforms dedb430979a4f6d5c8e6bf2ac9ac033fa66ba3af source-hash-d8dbe5844b192f1339a3d38e0f477c5330c89194 commit d8dbe5844b192f1339a3d38e0f477c5330c89194 Author: Tor Lillqvist <tml@iki.fi> AuthorDate: Fri Apr 12 19:50:13 2013 +0300 Commit: Tor Lillqvist <tml@iki.fi> CommitDate: Fri Apr 12 19:55:36 2013 +0300 Kill empty ImpDeInitWinTools() and the header with only its definition Change-Id: Ica82a4612da952c0c084974b708ef9dac753dcf6 6b5c2ccbb00bffc4890e92480cb00ea1f5042e15 source-hash-a1cd39a17216d78b4f335e6301786e205be14d0d commit a1cd39a17216d78b4f335e6301786e205be14d0d Author: vjinoch <elianoss@gmail.com> AuthorDate: Fri Apr 12 17:19:44 2013 +0200 Commit: Michael Meeks <michael.meeks@suse.com> CommitDate: Fri Apr 12 18:04:11 2013 +0100 fdo#60690 - Remove all calls t GTK_YIELD_GRAB because it does nothing. Change-Id: I76e76ec5fc85d8e1fd673a45b3e54163ca7643f3 We cannot bisect more!
Not sure why bibisectRequest was added to this again.
** Please read this message in its entirety before responding ** 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 Version: 6.2.0.0.alpha0+ Build ID: cec31fdedd7c94f4ebf903a66456a75867db22b0 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-21_22:54:44 Locale: ru-RU (ru_RU); Calc: threaded
Dear Christian Nieber, 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
Dear Christian Nieber, 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
Created attachment 177920 [details] The example file and its RTF version in Writer master Still a problem in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: eb69767d7c1bb8e6e780fd9503f08c9d7f5ecb45 CPU threads: 13; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded
In the RTF file the attribute {\sp{\sn fLine}{\sv 0}} is missing. It has the default value TRUE, so in case of no border it needs to be written out.
Created attachment 177925 [details] Proposed solution The attached patch solves the problem for me. But RTF filter is not my area, so someone else should have a look.
Thanks a lot -- could you please submit this to gerrit and CC me there? Happy review the patch & help out with the testcase if needed.
(In reply to Miklos Vajna from comment #11) > Thanks a lot -- could you please submit this to gerrit and CC me there? > Happy review the patch & help out with the testcase if needed. I'll do so, but need some days.
Created attachment 177960 [details] Examples to see the problem The problem is deeper. The current logic is not correct. The current 'if' catches only the case, that all four borders are set. With adding an 'else' for 'no border', the cases with only some borders set would change from 'all four default border' to 'no border'. So those cases would be still wrong. Open attached document and save it to RTF. Open the saved document. The borders have changed to default.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9877a0190e43241f4a5102e5d9cc7181f91d5a6f tdf#107727 disable border in RTF export if not drawn It will be available in 7.4.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.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/b3f426bc7ff75820c2487f1a7f9d0117b5d53831 tdf#107727 disable border in RTF export if not drawn It will be available in 7.3.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.