Created attachment 122688 [details] 400x100 sized example ods for MWE paste special with transpose activated fails with "There is not enough space on the sheet to insert here" for moderate-size tables (400x100 and transposed). There is enough space, especially it stays within the 1024 column limit and non-transposed paste works. MWE: open attached ods, select all, cut table, paste special with transpose activated.
Repro. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: a6f876d45bd4e41a7143594a6cb11b6893a0f620 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-11_00:07:38 Locale: fi-FI (fi_FI)
** 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 (5.2.5 or 5.3.0 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
still present in debian-stretch's lo 5.2.5.1
** 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 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
I can't reproduce this bug anymore. Version: 6.4.4.1 Build ID: 1:6.4.4~rc1-1 CPU threads: 6; OS: Linux 4.19; UI render: default; VCL: x11; Locale: de-CH (en_DK.UTF-8); UI-Language: en-US Calc: threaded
I just faced it. What I have is a file with 36 cols and 14 rows. When I do Ctrl + A and then copy and go to another sheet and paste special with transpose I get the error, but when I manually select the range of the cells that are not empty (36x14) I can paste it transposed. I guess something is wrong with Calc understanding the "area of interest". Version: 6.4.3.2 Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Flatpak Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Yeah, I actually still repro with attachment 122688 [details] Arch Linux 64-bit Version: 7.0.0.0.alpha1+ Build ID: bdc8cd060dca8a97ef7970d1c0ab30694930beea CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; Locale: en-US (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 14 May 2020
Reproduced with steps of comment 6 Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: f1b55d3f8e963069fc798bcf559ae9af2bf18b64 CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I've investigated this issue. All selected cells are taken into account. Also the empty cells. Steps to reproduce: i) Copying columns: 1. Write 1 in cell A1. 2. Select column A. 3. Copy 4. Go to cell B1. 5. Paste 6. --> It works and 1 is in cell B1. 7. Go to cell C2. 8. Paste 9. --> Error "There is not enough space on the sheet to insert here" 10. Go to cell A2 11. Edit > Paste Special > Transpose 12. --> Error "There is not enough space on the sheet to insert here" ii) The same is valid for copying rows. 20. Select column 1 21. Copy 22. Go to cell A2. 23. Paste 24. --> It works and 1 is in cell A2. 25. Go to cell B3. 26. Paste 27. --> Error "There is not enough space on the sheet to insert here" 28. Go to D1 29. Edit > Paste Special > Transpose 30. --> It works and 1 is in cell D1. (This case works as there are less cells in a row than a column. Copying everything is just copying columns (i.) and rows (ii.) combined. Pasting with skip empty cells of Paste Special does not change the behavior. The behavior of transposing seems consistent with the "normal" copy/paste. It is not really an issue of transposing. The solution is just to select and copy/paste/transpose the data that you want. With the current design of rows and columns in LibreOffice, I think there is no proper solution to this bug report (only for transposing). It would be a hack. A proper solution should handle the cases in steps 9., 12., and 27. together and keep the consistency.
It seems to me that paste should take into account how much of the source range is empty when determining space and when copying/inserting. To be safe, we should probably include some indicator in the source range that says "this is an entire column/row" as apposed to having a source range like A1...XF1 So, this is definitely not a simple problem to solve (because we would have to quite careful about when we trim off empty cells from the source range), but it should IMNSHO, be solvable
Dear documentfoundation, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
With attachment 122688 [details] I can [CTRL]+[HOME] and then [CTRL]+[SHIFT]+[END] to select the relevant range to copy (or cut) and then paste with transpose. This is one of several ways to select the used area. The 'paste special > transpose' command works as expected. The 'paste special > transpose' command is working correctly. The point about what or how to select the relevant area (only) so as to copy+paste is a different matter (not only relevant for this particular case). There are other reports related to what exactly [CTRL]+[A] and/or [CTRL]+[*] and/or other alternative selection methods do when applying some command after the selection. IMHO, this should be WFM now.
Reproduced with steps of comment 6 with LibreOffice 7.5.2.2
(In reply to Roland Kurmann from comment #13) > Reproduced with steps of comment 6 As long as you select the _whole_ worksheet (or an _entire_ column), transpose _will_ fail. If you select, say, 400 columns by 100 rows, you should be able to use transpose. As of LO 7.4, we have 16384 columns. If you select more than 16384 rows to transpose, the command has no alternative but to fail. As I mentioned in comment 12, the rest is not the main issue in this bug report. So the question is whether someone is still having a problem using transpose when selecting (a rectangle area of) less than (or equal to) 16384 columns by less than (or equal to) 16384 rows.
(In reply to ady from comment #14) > As long as you select the _whole_ worksheet (or an _entire_ column), > transpose _will_ fail. That's the bug. It's not unreasonable to expect the app to recognize that a limited number of rows and columns are populated when the user attempts a transposition. If that's not possible, then a better error message should be displayed.
> As of LO 7.4, we have 16384 columns. If you select more than 16384 rows to transpose, the command has no alternative but to fail. but I didn't select more than 2**20 rows. Maybe I technically did, but this is so unobvious. The scroll bars also don't extend over 16384 columns when basically all of them are empty, do they? Maybe the underlying technical reason for this bug is that ctrl-a doesn't select all non-empty cells or the hull rectangle around all nonempty cells. But this is still a manifestation of how ctrl-a does something else than what users reasonably expect it to do, even if they are somewhat aware that the size of the spreadsheet is what it is.