Created attachment 134809 [details]
Example

I think this is a normal behavior, its more the internal interpretation of how to ad data between to different applications. But this is more a guess than, but empty cells are empty and so there is nothing to copy

Those empty cells are copied when they are copied over other cells (inside LibreOffice), so they should also be copied to external applications.

Also, I noticed this bug when I was comparing data (in a text editor) between two documents. The data seemed to differ until I noticed that the second one was offset because of the missing cells at the top.

Reproducible. Marking as new, because empty cell between rows is copied:
1
2
3

4


repro with 4.2.8.2
Note: copy from excel->notepad works as reporter wants.

*** Bug 118163 has been marked as a duplicate of this bug. ***

(In reply to Xavier Van Wijmeersch from comment #2)
> I think this is a normal behavior, its more the internal interpretation of
> how to ad data between to different applications. But this is more a guess
> than, but empty cells are empty and so there is nothing to copy

Well, if I copied 5 rows, I expect to paste 5 lines, right?

Still a problem.

Version: 6.2.4.2 (x64)
Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64

Created attachment 152412 [details]
sample data

Comment on attachment 152412 [details]
sample data

This absolutely is not a normal behaviour. Imagine that a set of data that has been nicely prepared in Libre Calc (with leading empty cell) was then pasted to an external application. It could lead to data inconsistency or error.

To reproduce, in my attachment copy cells A2 to C4 and paste to notepad. The result in notepad would look like there was no A column in the spreadsheet.

Unlike Libre, Ms Office got it right by copying all cells including empty ones.

*** Bug 127600 has been marked as a duplicate of this bug. ***

Repro LO 6.4+. But this used to work as requested in LO 3.4. I'll mark regression from LO 3.5. Previously bibisect was available only from 3.6.

This should be the range:
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=43c7830b03d141ae11d8617c0fdabefa32dd243c..ce97851773a06103504972eb2771eecd7dd81e36

Not obvious which is the commit.
Maybe https://cgit.freedesktop.org/libreoffice/core/commit/?id=e747a4e87e6abf581a5b0c381f706b581c2a0fbc

(In reply to Timur from comment #15)
> This should be the range:
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?qt=range&q=43c7830b03d141ae11d8617c0fdabefa32dd243c..
> ce97851773a06103504972eb2771eecd7dd81e36
> 
> Not obvious which is the commit.
The range covers several months, so unfortunately not very helpful (but can't be helped, that's the granularity of this particular commit in the bibisect repo). Additionally, if the exact commit isn't identified, the usage of bisected keyword isn't warranted. Setting to notBibisectable instead.

Still a problem in 7.3.2.2 (x64)

Xisco, when building, can you try with a commit I wrote or maybe some probable?

Still a problem in 7.6.6.3

Still a problem in 26.2.2.2

Problem is an empty cell at start of the selection. In the text formats that LibreOffice puts into the clipboard, this empty cell is missing. In other formats, e.g. "HTML Format" or "Rich Text Format", the empty cell at start is included. An empty cell is include in the text formats, if it ia not at start but inbetween.

If an application is able to use formats like "HTML Format" or "Rich Text Format" then it gets the empty cell. Notepad++ or TextMaker show the empty cell at start, for example.

Line 1922
   if (!rDoc.ShrinkToDataArea( nStartTab, nStartCol, nStartRow, nEndCol, nEndRow ))
in https://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/impex.cxx?r=3c5f8e3dea0b3f352519ab3e361369a65f92aedb&fi=ExportString#1922

looks suspicious to me. But I have currently no access to my development environment. ShrinkToDataArea would do the observed behavior of ommitting empty cells at start or end. However, I know that ShringToDataArea was introduced be LibreOffice and does not exist in Apache OpenOffice.

There are pros and cons when "trimming" empty cells (i.e. not pasting the empty cells located at the extremes of the selected copied range). Some users / use-cases might prefer trimming them, and others might not.

"In-the-middle" empty cells are always considered, not skipped.

FWIW, AOO 4.1.6 does not trim the extreme empty cells when pasting to a simple text editor (such as Notepad).

Since there are pros and cons, if the current behavior of LO Calc were to be modified, some users / use-cases will be negatively affected.

I wonder whether there might be some (old?) setting / option somewhere in LO that affects this behavior (considering that each of the 2 contrasting possible behaviors has pros and cons, depending on use-case).

(In reply to ady from comment #26)
> There are pros and cons when "trimming" empty cells (i.e. not pasting the
> empty cells located at the extremes of the selected copied range). Some
> users / use-cases might prefer trimming them, and others might not.
> 
> "In-the-middle" empty cells are always considered, not skipped.
> 
> FWIW, AOO 4.1.6 does not trim the extreme empty cells when pasting to a
> simple text editor (such as Notepad).
> 
> Since there are pros and cons, if the current behavior of LO Calc were to be
> modified, some users / use-cases will be negatively affected.
> 
> I wonder whether there might be some (old?) setting / option somewhere in LO
> that affects this behavior (considering that each of the 2 contrasting
> possible behaviors has pros and cons, depending on use-case).

Originally, cells were not trimmed. At some point this was changed. And, it is pretty much counterintuitive to paste 3 rows when you selected and copied 5 of them.

Change was made by the following commit: https://github.com/LibreOffice/core/commit/2a26fe4a39b6f3b2af269b801340c32c28806250

(In reply to ajev.removic from comment #27)

> Originally, cells were not trimmed. At some point this was changed. And, it
> is pretty much counterintuitive to paste 3 rows when you selected and copied
> 5 of them.

Let's be clear that when you mention "paste 3 rows" you are specifically referring to pasting the extreme empty rows on a plain text editor; this is not related to pasting empty rows that are in the middle of the selected area, nor pasting on a spreadsheet.

Counter-intuitive is subjective. As I said, there are pros and cons. For instance, if you have tens of empty rows at the beginning or at the end, it is not of much real use to paste empty rows to a plain text editor at the beginning or at the end, but the selection of the area in the spreadsheet itself might still be easier (e.g. selecting an entire column).

Moreover, if you really need the extreme empty cells to be pasted to a plain text editor, the workaround is very simple; just (temporarily) add one character at the start / end of the selection.

OTOH, empty cells in whichever location of the selected area is always required for pasting within a spreadsheet, so the current behavior is useful in either case.

IMO, the current behavior is useful, and considering the pros and cons, I would not change it.

There is still the question whether there is somewhere some setting that would change the behavior. That is not part of the report, but rather for knowledge of users that might read it here.

BTW, reading tdf 46230 might be relevant. I do think this behavior should not be modified, other than having some experienced / advanced option somewhere (with the current behavior as default).

> it is not of much real use to paste empty rows to a plain text editor at the beginning or at the end

For your use-case maybe, but not for everybody.


> the workaround is very simple

There shouldn't be a need to use a workaround to copy some data in the first place. THIS is very counter-intuitive.

When I copy "something", I expect "something" to be pasted.
I definitely don't expect "something minus something else".

If someone needs to remove the empty cells/lines, they should do this after pasting, and not expect the software to automagically do it for them.

Only shrink to data area for entire document export | https://gerrit.libreoffice.org/c/core/+/205173

My concern with this change is that the data area will never shrink when a user creates a copy. In my opinion, this is a significant behavioral change, and I do not feel comfortable making the decision to merge such a substantial modification on my own.

Opinions? If we decide to merge this change, I will bring up an automated test.

How about an expert/user options configuration?

(In reply to Larsen from comment #31)
> > it is not of much real use to paste empty rows to a plain text editor at the beginning or at the end
> 
> For your use-case maybe, but not for everybody.
> 
> 
> > the workaround is very simple
> 
> There shouldn't be a need to use a workaround to copy some data in the first
> place. THIS is very counter-intuitive.
> 
> When I copy "something", I expect "something" to be pasted.
> I definitely don't expect "something minus something else".
> 
> If someone needs to remove the empty cells/lines, they should do this after
> pasting, and not expect the software to automagically do it for them.

Exactly.

(In reply to Larsen from comment #31)
> > it is not of much real use to paste empty rows to a plain text editor at the beginning or at the end
> 
> For your use-case maybe, but not for everybody.

That was exactly my point. I am not disregarding your use-case, but you also have to keep in mind that it is far more common to select an entire column with one click on its header than to specifically select a range.

I could provide many typical examples where the additional empty extremes would be counter-productive, but, again, I am not trying to disregard your use-case. What I am saying is that changing the current behavior has "cons", so imposing such change to everyone has negative consequences.

Additionally, as seen in tdf 46230, there are negative consequences on other (more important) areas, not only regarding pasting to an external plain text editor.



> 
> > the workaround is very simple
> 
> There shouldn't be a need to use a workaround to copy some data in the first
> place. THIS is very counter-intuitive.

Again, that is not my point. The current behavior allows for 2 different results; one as default, and another with a workaround. Changing the current behavior only allows for the second alternative behavior to survive (making it the default) while completely blocking the possibility of the current default behavior.

You are focusing on intuitive behavior (which is still subjective), while I focus on operative practical results.

> 
> When I copy "something", I expect "something" to be pasted.
> I definitely don't expect "something minus something else".
> 
> If someone needs to remove the empty cells/lines, they should do this after
> pasting, and not expect the software to automagically do it for them.


Again, that is your subjective expectation. A different expectation is to be productive, efficient. An example of such different expectation is when having Freeze rows, or data on one column that does not start at "the first row in a table". If you have many rows with empty cells, and non-blank cells are much lower, you still want to select a column header and copy the entire data, but you might not want to delete "who-knows-how-many" empty lines on a plain text editor. You describe what could be your case, but not everyone's, and for those, having to delete by hand empty lines of "text" is a waste of time, an undesired unexpected result.



(In reply to Andreas Heinisch from comment #33)
> How about an expert/user options configuration?

That is what I asked before, whether there is any option anywhere that changes the behavior. If there isn't such option anywhere already, having an expert configuration setting is one possible way to allow it.

Having "pros" and "cons" means that you cannot simply change the behavior without negative consequences to other users. Especially when situations such as tdf 46230 might be affected. This is not only about pasting on a plain text editor.

I suggested a very simple workaround in order for users to achieve the same result without having to wait for developers using their time and perhaps adding complexity to the code. Expert settings seems to be the other possible alternative.

Added an expert configuration where the current behaviour is the default case: https://gerrit.libreoffice.org/c/core/+/205173

Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/019479374854daa8660b1a36b48f1232aead0b0f

tdf#109299 - Shrink to data area on document export

It will be available in 26.8.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.

(In reply to Andreas Heinisch from comment #37)
> Added an expert configuration where the current behaviour is the default
> case: https://gerrit.libreoffice.org/c/core/+/205173

Thank you!