Description: 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: line1 line2 line3 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 ...) Actual Results: The text editor contains one single line that reads: line1 line2 line3 Expected Results: The text editor should contain3 lines: line1 line2 line3 Reproducible: Always User Profile Reset: No Additional Info: 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). /// Version: 6.1.0.3 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: LO 6.0.6: Line1 Line2 Line3 Test LO 5.4.7.2: "Line1 Line2 Line3" Test
Dear antoine.monmayrant+bugdocumentfundation, 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 reproducible with: Version: 6.4.0.0.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 Calc: threaded
*** 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: https://cgit.freedesktop.org/libreoffice/core/commit/?id=329eeefcbd65ea88f0c8c3f034d49ba73045d059 author Eike Rathke <erack@redhat.com> 2017-11-14 17:39:41 +0100 committer Eike Rathke <erack@redhat.com> 2017-11-14 17:40:15 +0100 commit 329eeefcbd65ea88f0c8c3f034d49ba73045d059 (patch) tree 05032ad9b703a1089c2a04a7ce68a8bb34cfd0f2 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"
Created attachment 200177 [details] short file demonstrating problem (LO calc not copying newlines.ods)
I am experiencing this also, and found this bug when coming to report it. Here is my report with version 24.8.5.2. 1. Use the attached file (LO calc not copying newlines.ods). Observe that the address fields are formatted with TEXTJOIN into a composite address field in column J. Note that newlines are contained in cells J2:J5 because of inserted CHAR(10) separating lines. This could be copy/pasted into another program such as to print lists or address labels. 2. Select any single cell in column J and copy it. 3. Paste into another program such as Emacs or Writer. Observe it correctly appears as 3 or 4 lines. 4. Now select more than one cell in J, such as J3:4 and paste that into the other program. --> Observe that the newline characters are missing, each replaced with a space. Expected behavior is for copy/paste to be consistent whether one cell is selected or more than one cell is selected, and to copy the data accurately -- preserving the newline characters in the data, when present. Alternatively, converting the newlines to spaces (or not) should be configurable. Version: 24.8.5.2 (X86_64) / LibreOffice Community Build ID: fddf2685c70b461e7832239a0162a77216259f22 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Is this issue possibly also causing bug 147279?
Maybe. But as people do not seem to read the source code comment as I mentioned in comment 11 especially along with bug 113571 I'm copy-pasting it here: + // Plain text ("Unformatted text") may contain embedded tabs and + // line breaks but is not enclosed in quotes. Which makes it + // unsuitable for multiple cells, especially if one of them is + // multi-line, but otherwise is expected behavior for plain text. + // For multiple cells replace embedded line breaks (and tabs) with + // space character, otherwise pasting would yield odd results. + /* XXX: it's debatable whether this is actually expected, but + * there's no way to satisfy all possible requirements when + * copy/pasting unformatted text. */
Previously, I didn't fully understand the ramifications of that comment. I think this explains the issue clearly: \n delimits the end of the data within a cell (for any copy/paste regardless of how many cells are copied). But if there are newlines within a cell, then it will be ambiguous as to whether a \n in the output is within the data contained inside a cell, or if the \n is indicating the end of the last cell in a row (during a multi-cell copy/paste). That is an interesting problem. A solution could be to specify what is used to delimit a cell and let it be different depending on whether the source cells contain \n characters and/or whether it is single cell or multiple cell copy. I will try to think about this more. Does anyone here know how this is handled by different software, such as Excel or Open Office? I don't have these to compare. Just to compare, Google Sheets handles it like this (I delimited each paste >located between angle brackets<): Using the file https://docs.google.com/spreadsheets/d/12pAOUOJn0SPNx8RsiOs95zWV4IgzenNQELjH-HzvK-A/edit?usp=sharing For a single cell not containing a newline: >line 1< For 3 cells, none containing a newline: >line 1 line 2 line 3< For one cell containing a newline: >"line A line B"< For 3 cells, two containing a newline: >"line A line B" line C "line D line E line F"< So any cell with a newline is quoted, and tab or \n marks end of any cell.
(In reply to Barry L. Kramer from comment #18) > Does anyone here know how this is handled by different software, such as > Excel or Open Office? I don't have these to compare. OpenOffice doesn't even know line breaks in formulas (as per this bug's summary). For non-formulas like in your GSheet example copy-pasting B3:C5 it does line 1 line A line B line 2 line C line 3 line D line E line F which is about the worst you could get. I don't have Excel. > Just to compare, Google Sheets handles it like this > So any cell with a newline is quoted, and tab or \n marks end of any cell. Which seems to be a regular TSV (tab separated values) export with optional double quotes when needed. Doable if we agree on it, but would change current usage flow and come unexpected. That For one cell containing a newline: "line A line B" would come very unexpected though, because currently the plain text including newline is pasted without any additional quote characters, and I think at least that should be kept.
I agree it is important to not do anything unexpected. And certainly the way it is now without the quoting is good if someone wants it more human readable. Others may want or need the multi-line cells always quoted (even if only one cell is copied, such as an address like I'm using). Perhaps this is an example of where it could be configurable with the default setting giving the same behavior as now. If something like a checkbox "Always quote multi-line cells" was in Tools - Options - LibreOffice Calc - Compatibility, then that could work? Maybe in a new section for Interoperability? Alternatively (see attached mock-up), a pull-down list "Copy cells externally" {Default | Quote multi-line cells | Quote all copied cells"? The latter would give user the choice of the current method, or the way Google Sheets (and probably excel) do it, or a method where all data is quoted. An additional checkbox (defaulted off) "Also apply to single cell copy" could control the behavior to quote single multiline cells, so the copy gives consistent results no matter how many or how few cells are copied. Just some ideas.
Created attachment 200274 [details] mock-up of possible configuration setting