When copy-pasting multiple cells from Calc to a text editor, the newline present in the cells are ignored in LibreOffice Calc 6.x leading to unexpected copied text.
The bug is confirmed under both Linux and Windows and was not present in LibreOffice Calc 5.x.
Steps to Reproduce:
1. Create a cell (let's say A1) with a multiline content like (typed using Ctrl+Enter for line breaks:
2. Select both A1 and A2 (A2 can be empty)
3. Copy (Ctrl+C) the content of the cells
4. Paste as text in a text editor (notepad++, notepad, gedit, kate ...)
The text editor contains one single line that reads:
line1 line2 line3
The text editor should contain3 lines:
User Profile Reset: No
1) This bug is a regression: the normal behavior has been confirmed under both Linux & Windows using LibreOffice Calc 5.x versions.
2) This bug is only triggered when more than 1 cell is selected. If only the cell A1 in the above example is selected, the pasted text is correct (ie multiline).
3) This bug has been confirmed under Linux (Ubuntu 16.04 64bits) & Windows (7 pro 64 bits).
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 16; OS: Linux 4.4; UI render: default; VCL: gtk2;
Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded
Created attachment 144938 [details]
File to trigger the bug (contains detailed steps to reproduce the bug)
Here is a sample file to reproduce the bug.
confirming different behaviour:
Line1 Line2 Line3
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!
still reproducible with:
Version: 18.104.22.168.alpha0+ (x64)
Build ID: c5d37d324cd6d17114c209de1862344ad58a1d93
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
Locale: de-DE (de_DE); UI-Language: en-US
*** Bug 143915 has been marked as a duplicate of this bug. ***
No repro 5.4.7, repro 6.0 and 7.3+.
Windows paste to Notepad++ looses LF from LO 6.0 (this bug).
Paste to MSO Excel writes "multi" and loses "line" even before.
Paste to FreeOffice PlanMaker pastes properly before and after.
*** Bug 142277 has been marked as a duplicate of this bug. ***
*** Bug 142561 has been marked as a duplicate of this bug. ***
*** Bug 128513 has been marked as a duplicate of this bug. ***
Regression introduced by:
author Eike Rathke <email@example.com> 2017-11-14 17:39:41 +0100
committer Eike Rathke <firstname.lastname@example.org> 2017-11-14 17:40:15 +0100
commit 329eeefcbd65ea88f0c8c3f034d49ba73045d059 (patch)
parent ed89b432dff252d3b1a18ad7694bbf2c4abc36ff (diff)
Distinguish single/multiple cell copy for plain text, tdf#113571 follow-up
Bisected with: bibisect-linux64-6.0
Adding Cc: to Eike Rathke
Read the source code comment in that commit.. in conjunction with bug 113571.
I'm in favor of an option in Calc, if possible.
There will always be 2 groups of users and neither option is better.
Problem now is that more general behavior is unexpected.
Let me update this, interesting that behavior of editors is different:
> Windows paste to Notepad++ looses LF from LO 6.0 (this bug).
> Linux paste to Gedit keeps LF with quotes.
> Paste to MSO Excel writes "multi" and loses "line" from before.
> Paste to FreeOffice PlanMaker pastes properly before and after.
> Paste to WPS pastes "multi" and "line" in separate rows.
My understanding in most other applications preserve the intra cell line breaks by
* Using the more advanced formats where possible eg html or rtf (both to read & write to the clipboard).
* Write to the clipboard, quoted special characters if required to preserve linefeeds. (Such as Microsoft Excel and Google Sheets)
This also happens transparently between LO applications.
LO Calc supports quoted intra-cell line feeds when reading the clipboard
LO Calc supports quoted intra-cell line feeds when saving as a CSV file
The time intra-cell line feeds are not preserved is when copying from LO calc to an applications which does not support formats other than plan text.
So I am not convinced that "more general behavior is unexpected"