Created attachment 197390 [details] Tail end of text disappears when copy pasting a cell from Excel to Calc In the attached example Excel document, there is a cell, from which the end of the text disappears, if you copy&paste the cell from MS Excel (Windows) to LibreOffice Calc. Copying from Excel to another Excel works fine. I tested the bug on the latest stable LibreOffice version: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: fi-FI (fi_FI); UI: en-GB Calc: threaded and I also tested that the exists on LO version 5.4.7. Propably even earlier version are affected, but I have not tested. Contents of the cell is: "qqqqqqqqqq wwwwwwwwww eeeeeeeeee rrrrrrrrrr tttttttttt yyyyyyyyyy uuuuuuuuuu iiiiiiiiii oooooooooo pppppppppp aaaaaaaaaa ssssssssss dddddddddd ffffffffff gggggggggg hhhhhhhhhh jjjjjjjjjj kkkkkkkkkk llllllllll zzzzzzzzzz xxxxxxxxxx cccccccccc vvvvvvvvvv bbbbbbbbbb nnnnnnnnnn mmmmmmmmmm qqqqqqqqqq wwwwwwwwww eeeeeeeeee rrrrrrrrrr tttttttttt yyyyyyyyyy uuuuuuuuuu iiiiiiiiii oooooooooo pppppppppp aaaaaaaaaa ssssssssss dddddddddd ffffffffff gggggggggg hhhhhhhhhh jjjjjjjjjj kkkkkkkkkk llllllllll zzzzzzzzzz xxxxxxxxxx cccccccccc vvvvvvvvvv bbbbbbbbbb nnnnnnnnnn mmmmmmmmmm" After copy paste: "qqqqqqqqqq wwwwwwwwww eeeeeeeeee rrrrrrrrrr tttttttttt yyyyyyyyyy uuuuuuuuuu iiiiiiiiii oooooooooo pppppppppp aaaaaaaaaa ssssssssss dddddddddd ffffffffff gggggggggg hhhhhhhhhh jjjjjjjjjj kkkkkkkkkk llllllllll zzzzzzzzzz xxxxxxxxxx cccccccccc vvvvvvvvvv b"
About the used Excel version, I have tested this on Excel versions 2013 and 2019 on Window 11.
Only the first 255 characters are pasted. If you right-click on the arrow at the right of paste icon, you can select other types to paste Simple HTLM seems to work as expected Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 665dce4442e48b133b9fe1a2eb792ed3ef81d90c CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
*** This bug has been marked as a duplicate of bug 127675 ***
FTR: despite this talks about characters in a single cell, and bug 127675 is about number of rows, this is a duplicate of bug 127675 nevertheless, because they are both about missing support for BIFF12 clipboard format, and what's used is obsolete BIFF8 clipboard format, containing only what Excel 2003 could contain (up to 255 characters per cell, up to 65536 rows, up to 256 columns, etc.)
Additional data point, that doesn't change much. In fact, Biff8 (Excel 97-2003) *is* able to store more than 255 characters per cell. The LabelSst record (253), that is intended to represent a cell with a text, pointing to a shared string, allows that. Saving a file with the text like in comment 0 from Excel in 97-2003 format keeps the data, and LO can read it just fine. And what's even more interesting, Excel does store the whole length of the cell content as a shared string in the clipboard data. Using NirSoft InsideClipboard, you can inspect the data, and see the whole string in the Biff8 blob, around offset 000035F0. The fun is, that Excel exports Biff8 *incorrectly* to clipboard: unlike the store-to-file case, where it indeed stores the LabelSst record, in case of clipboard, it stores Label record (516), which is used for a different thing: "a label on the category axis for each series" (i.e., for charts), near offset 00004EC0, with its own data; again, it is in theory capable to store up to 65535 characters - but only 255 is really stored there. If you copy the data from Excel to clipboard, then open MS Word, there use Paste Special, and choose Excel 2003 format, you will get an OLE object inserted; double-clicking it activates Excel, showing the same picture: the resulting cell only has 255 characters. So without moving to Biff12, there is no chance for LibreOffice to get the correct data. Ref.: [MS-XLS] https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-xls
Created attachment 197397 [details] A clipboard data from Excel
(In reply to Mike Kaganski from comment #5) > ... Thank you Mike for the detailed technical explanation, very interesting. This data loss issue seems rather dangerous to me, and from all of these Biff8/12 related issues, I think this cell content length limitation is the one that an average user is most likely to bumb into. Using over 65536 rows or over 256 columns in a document is IMO very uncommon, but using over 255 characters in cell is much more common. I think it is also easier to notice that all rows or columns are missing beyond some number, but it harder to notice if some cells have some their content cut off. Would it be difficult to implement some kind of warning of possible data loss, if LO encounters clipboard with Biff8 and Biff12 objects, and the Biff8 object contains 65536 rows, 256 columns, or 255 characters in some cell.