1. New Text Document. 2. Type “This is a test.” and Return. 3. Open up wordpad. 4. Type "simple". 5. Copy “simple” from wordpad. 6. In LO, place the cursor before "test" and paste. Result: A paragraph is inserted after "simple". If you type "This is a simple test." in wordpad and copy "simple", then the result is the same. A similar result can be obtained without the use of wordpad by copying "test" and placing the cursor after "This", then Paste Special → More Options → Formatted text [RTF]. Result: A paragraph is inserted after “Thistest”. Is this behaviour by design? Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Reproducible with LO 4.4.1.2, Win 8.1. I don't think that this bahviour can be desired.
Adding Cc: to todventtu@suomi24.fi; if you get a minute, could you get a raw clipboard capture for this one too? Thanks
Created attachment 114664 [details] RTF data from Wordpad Captured with http://www.nirsoft.net/utils/inside_clipboard.html Saved as .rtf
@Beluga: Thanks for providing the file. Using it, I can reproduce on Linux as well. Loading the RTF directly gives only the word "simple" with no linefeed, as you would expect. Copying it to the clipboard using $ cat ~/Downloads/simple.rtf | xclip -t text/rtf -selection clipboard and pasting into LO produces the issue described - there is an extra paragraph This doesn't occur in LO 3.3.0, so this is a regression.
Bibisect result from 43all: commit 16817aeb240d8066676540c467a7e4aac00ed008 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 08:58:33 2012 +0000 source-hash-4026e1824de8ff9b5d006ae6eba491f91bc4e599 commit 4026e1824de8ff9b5d006ae6eba491f91bc4e599 Author: Markus Mohrhard <markus.mohrhard@googlemail.com> AuthorDate: Fri Nov 30 22:19:45 2012 +0100 Commit: Markus Mohrhard <markus.mohrhard@googlemail.com> CommitDate: Fri Nov 30 22:19:45 2012 +0100 It looks pretty likely from the commits in that range that the below is the point the extra paragraph appeared. Adding Cc: to vmiklos@collabora.co.uk; Any thoughts on this one? Thanks commit ed654c4aa7f9f10fcb16127349009bc0c38b12e8 Author: Miklos Vajna <vmiklos@suse.cz> Date: Fri Nov 30 17:37:08 2012 +0100 Revert "fdo#43869 use the old rtf importer for paste" This reverts commit bb147bbb801b53dba8928340df7e2aa2d4545349. It's no longer needed, now the new importer supports importing to an existing document.
See also bug 70318, it's basically the same problem. Let's use this bug for the problem that during paste, \par or no \par at the end of the document ends up in the same import result while it should not -- and the other bug for the problem that once there is a difference, it's not 0 vs 1 paragraphs, but 1 vs 2.
Created attachment 115509 [details] RTFs with different endings Just note that there is a difference on how RTF should be treated when it is open from file vs when it is pasted from clipboard. Attached are three Hello world RTFs, that only differ by ending \par. There is a version without \par at the end, with one \par and with two of them. If you open them with WordPad or MS Word, both versions without \par and with single par will NOT have empry paragraph at the end (after Hello world!). Only when there are two \par's, it will have single empty paragraph there. But if you put the same data to clipboard, and then paste it to WordPad or MS Word, you will have two newlines when there are two \par's, one newline for one \par, and no newlines when there's no \par. That's also the case with any text copied from LO: it gives newline when pasted to WordPad when it should not, because LO always adds \par at the end.
Please let's keep this bug only for the regression part, i.e. this should be marked as resolved when the behavior is as good as what we had in LO 3.3. Let's use bug 70318 for the non-regression discussion. :-)
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e702c78843e387d83fd9c8fbd1597cbe27e3e656 tdf#90260 writerfilter: pasted RTF documents may contain no \par 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8931abc0b9fded1ee78eca6bf28e8d2438a76add tdf#90260 testcase 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.
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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]