Description: When looking to paste from LibreOffice to a different application, LibreOffice does not seem to advertise the Biff formats. Steps to Reproduce: 1. Select cells in Calc 2. Copy 3. Run "wl-paste -l" Note that no Biff format appears in the list: application/x-libreoffice-internal-id-77346 STRING UTF8_STRING text/plain;charset=utf-8 text/richtext text/rtf application/x-libreoffice-tsvc text/plain;charset=utf-16 application/x-openoffice-dif;windows_formatname="DIF" application/x-openoffice-link;windows_formatname="Link" application/x-openoffice-sylk;windows_formatname="Sylk" text/html image/bmp application/x-openoffice-bitmap;windows_formatname="Bitmap" image/png application/x-openoffice-wmf;windows_formatname="Image WMF" application/x-openoffice-emf;windows_formatname="Image EMF" application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile" application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="LibreOffice 7.3 Spreadsheet";viewaspect="1";width="18063";height="4517";posx="0";posy="0" application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" Actual Results: No Biff format advertised Expected Results: Advertise a Biff format for copy/paste Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.3 Calc: threaded
This is not a bug report. You do not explain *why* should it do that. I.e., which actual problem would be solved if it did; what is impossible in the current situation.
Also please use recent LO versions (see https://launchpad.net/~libreoffice/+archive/ubuntu/ppa). Indeed, 7.3 as 7.4 branches are EOL.
(In reply to Mike Kaganski from comment #1) > This is not a bug report. You do not explain *why* should it do that. I.e., > which actual problem would be solved if it did; what is impossible in the > current situation. The problem being solved is that copy/paste between spreadsheet-like applications does not seem to copy formulas or formatting reliably. Originally, I assumed that Sylk format did so, but it does not (bug filed) and turns out to be a very obsolete format. Am I missing something? Are one of the advertised formats actually transmitting formulas and formatting information via copy/paste? My presumption was the Biff8 or Biff12 would do so and it appears the LibreOffice already understands those formats as it can deal with Excel files. I also presumed that support already existed and the bug was in advertising rather than implementation. Gnumeric for example advertises: $ wl-paste -l STRING COMPOUND_TEXT UTF8_STRING text/html application/x-openoffice-biff-8;windows_formatname="Biff8" _CITRIX_Biff8 Biff8 application/x-gnumeric I assumed that the existence of "application/x-openoffice-biff-8;windows_formatname="Biff8"" in Gnumeric was not spurious. Of course, you know what they say about "Assume" ...
(In reply to Julien Nabet from comment #2) > Also please use recent LO versions (see > https://launchpad.net/~libreoffice/+archive/ubuntu/ppa). > Indeed, 7.3 as 7.4 branches are EOL. That may be, but they are the versions that are the current snaps on Ubuntu 22.04.3 LTS (released August 2023). However, if this *is* supported in a newer version, I will go through the grief of forcing my system to upgrade the version.
This is a case of XY problem. So is the actual problem "Pasting to Gnumeric does not transfer formulas"? This problem could have different solutions, and the "let's support an arbitrary *external*, *proprietary*, *non-generic* clipboard format on Linux" option should not be the preferred solution - why not think about "introduce a clipboard format based on standardized markup - like ODF"? That would be a task for both LibreOffice and Gnumeric - but it would be more in line with the overall phylosophy of all the involved projects (Linux; LibreOffice; Gnumeric)... Or what about text/html? May we have a variant that transfers formulas?
Please back up. The questions on the table are: 1) Is the LO Calc Biff8 advertisement for Copy/Paste broken? This has a question that probably needs to be answered prior to that: 1a) Does LO even support Biff8 for Copy/Paste? I *presumed* that the answer to this was "yes" based upon the fact that Gnumeric goes out of it's way to advertise such a thing (presumably as a target for OO/LO). However, that may *not* be a correct presumption and it would be good to get that answered authoritatively. 2) Do one of the currently advertised formats transmit formulas and formatting for Copy/Paste? I will happily use one of the other formats if they do so. However, my cursory inspection of all the different formats seems to indicate that none of them reliably transmit formulas and formatting. (In reply to Mike Kaganski from comment #5) > This is a case of XY problem. So is the actual problem "Pasting to Gnumeric > does not transfer formulas"? This problem could have different solutions, > and the "let's support an arbitrary *external*, *proprietary*, *non-generic* > clipboard format on Linux" option should not be the preferred solution - why > not think about "introduce a clipboard format based on standardized markup - > like ODF"? That would be a task for both LibreOffice and Gnumeric - but it > would be more in line with the overall phylosophy of all the involved > projects (Linux; LibreOffice; Gnumeric)... > > Or what about text/html? May we have a variant that transfers formulas? Any of these would be awfully nice. Might I request support for application/x-kspread-snippet? Nevertheless, if I'd like to get something working in the near future, practically everything that works on tabular data already understands Biff8 or Biff12. This includes things like Gnumeric, pandas, Apache POI/Arrow/Spark, as well as everything in the Windows ecosystem and *including LO*. Thanks.
1. There is no problem *generally* with Biff *paste* into LibreOffice - at least on Windows, as shown in tdf#127675 - only Biff12 support is missing, which is an easyhack there. 2. You issue seemed to me initially a duplicate of tdf#124006 - because the underlying issue looked the same. However, that one was for Windows, and bug 124006 comment 1 directly told it working for Linux - but that must mean, that there *is* a clipboard format on Linux, that different apps may use to transfer formulas. Needs investigation.
(In reply to Mike Kaganski from comment #7) > 1. There is no problem *generally* with Biff *paste* into LibreOffice - at > least on Windows, as shown in tdf#127675 - only Biff12 support is missing, > which is an easyhack there. > 2. You issue seemed to me initially a duplicate of tdf#124006 - because the > underlying issue looked the same. However, that one was for Windows, and bug > 124006 comment 1 directly told it working for Linux - but that must mean, > that there *is* a clipboard format on Linux, that different apps may use to > transfer formulas. Needs investigation. I opened two different LO instances and pasted between them. Consequently, I can confirm that "application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" appears to transmit formulas. I did not realize that this was xml in a zip archive and so only scanned it directly. Once I unpacked the archive, I could see the formulas. I can make personal progress doing what I need to do on Linux even though it's going to be a lot more work. As such, the severity can be downgraded or the bug closed at your discretion.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Andrew Lentvorski from comment #3) > I also presumed that support already existed and the bug was in advertising > rather than implementation. Gnumeric for example advertises: > [...] > application/x-openoffice-biff-8;windows_formatname="Biff8" > _CITRIX_Biff8 > Biff8 > [...] > I assumed that the existence of > "application/x-openoffice-biff-8;windows_formatname="Biff8"" in Gnumeric was > not spurious. Of course, you know what they say about "Assume" ... I tested OpenOffice.org 3.3 and I get: xclip -selection clipboard -t TARGETS -o text/plain;charset=utf-8 text/plain;charset=UTF-8 UTF-8 UTF8_STRING COMPOUND_TEXT STRING application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="calc8";viewaspect="1";width="4517";height="851";posx="0";posy="0" application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile" application/x-openoffice-emf;windows_formatname="Image EMF" application/x-openoffice-wmf;windows_formatname="Image WMF" application/x-openoffice-bitmap;windows_formatname="Bitmap" PIXMAP image/bmp text/html application/x-openoffice-sylk;windows_formatname="Sylk" application/x-openoffice-link;windows_formatname="Link" application/x-openoffice-dif;windows_formatname="DIF" text/richtext MULTIPLE ... so it doesn't look we ever supported it as a target. So, seeing this, Mike's input and Andrew's last comment, I'd say this is a "won't fix". I agree open standards should be promoted for anything coming out of LO. If there are issues with formatting and formulas not being copied properly from LO to other software, let's focus on those issues and fix our existing targets. Thank you!