Description: Pasting only 65536 rows to Calc from Excel possible a problem with selecting of right format for pasting from clipboard in LibreOffice Calc Steps to Reproduce: 1. Open XLSX file from attach 2. Copy cell range A1:A100000 3. Try paste it into Calc => will be paste only 65536 rows instead of all 100000 Actual Results: Pasting only 65536 rows to Calc from Excel Expected Results: Pasting all data from Excel to Calc Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.0.0.alpha0+ (x64) Build ID: 06925c1230cd6269fa5189ac3f4d608c9edf68e9 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-17_00:45:28 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
Created attachment 154330 [details] Example XLSX with 100000 rows with data
Open file from attach in Excel of course =(
Excel (tested with ver.2016) stores these formats to clipboard: CF_TEXT CF_BITMAP CF_METAFILEPICT CF_SYLK CF_DIN CF_UNICODETEXT CF_ENHMETAFILE Embed Source Link Source Object Descriptor Link Source Descriptor HTML Format Rich Text Format Hyperlink Csv Link Biff8 Biff5 XML Spreadsheet Biff12 The Biff8 is what is chosen by Calc when pasting (see ScViewFunc::PasteFromSystem()). It is a format that is limited to 256 columns and 65536 rows, hence it can't contain everything that Excel is capable to store to clipboard (Biff5 has the same constraints). "XML Spreadsheet" format seems to be the Excel 2003 XML format; and Biff12 is "Excel Binary Workbook" (.xlsb), which is the format supported by LibreOffice (read-only) and doesn't have the limitation of the older Biff formats. The Biff8 clipboard format support was added in commit https://git.libreoffice.org/core/+/f5412bb121481cf1e48af4d6dc10674bec6c095c. Adding "easyhack" keyword.
So the idea is to add the Biff12 Clipboard format support, which would take precedence over the other two Biff formats on import.
Re-evaluating the EasyHack in 2023 This issue is still relevant. I've tested this with MS Office 2019 and both LO 7.5 and the latest LO 7.6 dev master, and the problem is still there: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 32; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 23bd3bd10e74b0c23c2654d02d7d830e7693adac CPU threads: 32; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded
*** Bug 87843 has been marked as a duplicate of this bug. ***
I don't have Excel on my machine, but I can open the file using Excel in the browser (Edge on Win10). Copying and pasting this way goes through a different path than Biff8; specifically, it goes through the HTML_SIMPLE path and somehow this also manages to fail and the text that is pasted into the cell is "The selection you're trying to copy and paste is too large. Select a smaller set of data and try again.". So, is this different path a different bug, or should that also be fixed with this bug?
(In reply to Matt K from comment #7) This is different, and needs an own report and fix. Thanks for looking!
(In reply to Mike Kaganski from comment #8) > (In reply to Matt K from comment #7) > > This is different, and needs an own report and fix. Thanks for looking! Filed Bug 156214 for that
*** Bug 163759 has been marked as a duplicate of this bug. ***
Laurent Balland committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ba49c9249fcfec8891ef7d53dc8c9db1715df020 tdf#127675 Treat Biff12 when pasting It will be available in 26.2.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 Commit Notification from comment #12) > Laurent Balland committed a patch related to this issue. > Affected users are encouraged to test the fix and report feedback. I tested this by copying a range consisting of 120k rows, 340 columns from Excel 2013 to Calc 26.2.0.0.beta1. First row had cells with 700 charachters and other cells in columns had numbers 1,2,3,4,5...120000. Pasting took maybe 20 seconds and seems to have worked fine. Thank you very much for fixing this issue! I think the 256 characters per cell limit was most annoying and dangerous, because it was so difficult to detect the missing characters. With rows and colums it was easier see that not all of the rows or columns were transfered. Version: 26.2.0.0.beta1 (X86_64) Build ID: 620(Build:0) CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: fi-FI (fi_FI); UI: en-GB Calc: CL threaded
(In reply to Commit Notification from comment #12) > Laurent Balland committed a patch related to this issue. > Affected users are encouraged to test the fix and report feedback. In my previous comment I concluded that I managed succesfully copy/paste BIFF12 data from Excel 2013 to Calc 26.2.0.0.beta1. Now I find that saving the .ods document that I pasted data from Excel 2013 always crashes. Even with very small content pasted. Does this happen to anyone else? Saving a naturally created LO calc document with 120k rows, 350rows and some cells having 700 works. Working with this huge document does get into some performance issues, but saving it does work.
(In reply to devseppala from comment #14) > In my previous comment I concluded that I managed succesfully copy/paste > BIFF12 data from Excel 2013 to Calc 26.2.0.0.beta1. > > Now I find that saving the .ods document that I pasted data from Excel 2013 > always crashes. Even with very small content pasted. Does this happen to > anyone else? Please create a new report for it with a minimal sample that reproduces the issue.
(In reply to Buovjaga from comment #15) > (In reply to devseppala from comment #14) > Please create a new report for it with a minimal sample that reproduces the > issue. @Buovjaga, producing a sample document is a bit difficult as the saving process crashes and hangs, and I have to manually end the LO process. Thus there is no document to send. I will do a new report on the subject little later.
Reproducible; no sample nor new report needed. I will fix the implementation.
https://gerrit.libreoffice.org/c/core/+/196161
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a616d6f20f95735d4db4af1c102b40c9c98c2080 tdf#127675: SfxObjectShell::DoLoad takes ownership of the passed medium 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/8a3e2956c69670929123f01c6baa0a1f92f2c2d7 tdf#127675: SfxObjectShell::DoLoad takes ownership of the passed medium It will be available in 26.2.0.2. 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.