Problem description: [1] Create new text document. [2] Display non-printing characters. [3] Insert two paragraphs with just 1 short sentence each. [3] Select first word of first sentence with double-click. [4] Copy to clipboard: Ctrl+C. [5] Move cursor between two words of second sentence. [6] Paste clipboard as formatted text with: Edit → Paste Special... → Formatted text [RTF] → OK: The word plus an end paragraph character is inserted, i.e. the sentence is split to two paragraphs. Expected: Only the word without an end paragraph character should be inserted. Bug already exists in Version 3.4.x I did the same tests with WordPad, whose standard format is Rich text. With WordPad no paragraph end character is inserted. Operating System: Windows 7 Version: 4.1.1.2 release
Reproducible since 3.3.0.4 and in AOO 4.0.
accoring to comment #1 an old issue also the word, number of words, and line from which you copy are not relevant
Appologies for setting severity to Normal, while it rightfully was set to Minor initially!
Miklos, adding you as you suggested in c#9 of Bug 68291.
** 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 on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Repro still. Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64) Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9 TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50 Locale: fi_FI
Submitted patch to gerrit: https://gerrit.libreoffice.org/15697
Thanks, will have a look at the patch.
See also bug 90260 (that's how we almost managed to step on each others legs with Mike).
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ddd9f9ff45f61013ea18763eca4c68aedce6caa tdf#70318: don't forget to clean up second fake paragraph It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Mike, I've now pushed what I *think* to be correct, but I may have overlooked something. Please submit a follow-up patch if you're not happy with what's in master -- the only thing I plan to do on master around this is adding a unit test for bug 90260, so that *that* document is imported without a newline. The rest is up to you, I don't have strong opinion on that. ;-) Thanks a lot, Miklos
(In reply to Miklos Vajna from comment #11) Thank you very much! You are absolutely right, and your patch to bug 90260 seem to handle everything brilliantly!
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f44ff6044e4ea20a3a40f65b3762fa0171b20e6e&h=libreoffice-4-4 tdf#70318 tdf#90260 writerfilter: pasted RTF documents may contain no \par It will be available in 4.4.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Checked with versions 4.4.5 and 5.0.1. In both versions the bug is not fixed. Hence set back to NEW.
Yep, it's not fixed. Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI)
Well, it's not actually "not fixed". Previously, you could copy formatted text from ANY application, e.g. from WordPad, and pasting it as RTF resulted in extra newline appended. Now, only when you copy from LO, and then paste back to LO as RTF, you get that newline. When the source is another app, everything is as expected. Tested with Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: ru-RU (ru_RU) and with Version: 5.1.0.0.alpha1+ Build ID: e72e8c59fb1103f46b3d0b3e6a2386566068b1a2 Locale: ru-RU (ru_RU) under Win10x64. Seems like a part responsible for copy is affected, because the clipboard data already contain that needless newline: pastion from LO to RTF adds that newline, too.
A patch is submitted to gerrit: https://gerrit.libreoffice.org/19718
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6ae84cc296d4d28e9a48a57406e955138c87a80 tdf#70318: Prevent extra empty paragraph in clipboard RTF content It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Checked with versions 5.0.4.2 and 5.1.0.3: Bug still exists with 5.0.4.2, but in version 5.1.0.3 it's fixed. Hence status set to Resolved Fixed.