bugPSPP - Bugs: bug #65288, Copy&Paste of tables from...


bug #65288: Copy&Paste of tables from output view does not copy graphics but text

Submitter:  Friedrich Beckmann <beckmanf>
Submitted:  Sat 10 Feb 2024 04:14:26 PM UTC
Category:  Graphical User Interface Severity:  5 - Average
Status:  Confirmed Assigned to:  None
Open/Closed:  Open Release:  None
Effort:  0.00
* Mandatory Fields

Add a New Comment Rich Markup

Sun 02 Jun 2024 07:18:59 PM UTC, comment #5: 

I made a merge request to gdk to fix the html mime<->uti problem on MacOS:

Friedrich Beckmann <beckmanf>
Group Member
Sun 02 Jun 2024 05:55:05 PM UTC, comment #4: 

I added a commit in pspp to restrict the advertised data formats on the clipboard.


This helps the applications to choose the correct format. For charts no html or text format is advertised. For tables no image format is advertised.

Friedrich Beckmann <beckmanf>
Group Member
Sun 02 Jun 2024 01:16:59 PM UTC, comment #3: 

My idea was to fix this in gdk such that mime types are translated to the MacOS UTI style:


This would also translate the mime "text/html" to uti "public.html". It turns out that applications have different "preferred" formats from the clipboard. You have switched off the image targets for tables with the patch mentioned below to influence the libreoffice clipboard choice. If image targets like png are available on the clipboard, then libreoffice prefers the image targets. Libreoffice also allows to choose from other formats via "Paste Special" but other applications do not have that option. So basically we decide via our advertised formats how data is imported in different applications.

It turns out that some applications prefer "html" over "images". But our "html" export for charts just mentions the image file. So we would need to disable "html" from the announced formats on the clipboard for charts. Currently advertised formats with my above gdk patch are


  • public.plain-text
  • public.utf8-plain-text
  • public.html
  • public.jpeg
  • public.png
  • com.microsoft.bmp
  • public.svg-image
  • org.oasis-open.opendocument.text

The following applications import charts via clipboard as follows:

Libreoffice: png image
Apple Mail, Notes: A kind of empty box - I guess from the html with the link to the local file system which is not safe)
Apple Keynote: The plain or utf8 text with the name of the file of the image
Inkscape: png image

This is interesting as inkscape imports as png but without my gdk patch, the svg is advertised as "image/svg+xml" on the clipboard and inkscape imports svg then. So at least inkscape needs the svg mime advertised and ignores the svg uti. But inkscape is gtk/gdk based and would probably use the same method if fixed in gdk.


  • public.plain-text
  • public.utf8-plain-text
  • public.html
  • public.svg-image
  • org.oasis-open.opendocument.text

The applications import the following format:
Libreoffice: html table
Apple Mail, Notes: html table
Apple Keynote: svg
Inkscape: nothing

So Apple Keynote prefers the svg for tables but not for charts. Strange. Without my gdk patch, inkscape imports the svg.

Anyway, I think the mime to uti conversion for "text/html" should be done and it should be done in gdk for all applications. Maybe with a less intrusive patch such that just "text/html" is converted and not everything. Not sure.

For pspp I think the current implementation is based on wrong assumptions. We make this target list


and later add text and image targets:


However, adding a target via gtk_target_list_add_text_targets is misleading as this adds a bunch of text targets to the list:


what we have already done via the array. What we will receive as callback identifier like "SELECT_FMT_UTF8" is not clear. I guess the list will be searched from the beginning such that all "gtk_target_list_add_text_targets" are obsolete.

The same holds for gtk_target_list_add_image_targets. This just adds all targets which can be produced by a gdk_pixbuf. See:


This does not include svg, so we do in fact not add the svg target by that call. It was already in the array.

But I think the idea is correct that we want different advertised targets depending on our widget type, i.e. different targets for charts and tables.

Friedrich Beckmann <beckmanf>
Group Member
Sun 02 Jun 2024 09:05:56 AM UTC, comment #2: 

Thanks for looking into this Friedrich.  If your suggested change fixes the problem, then I suggest that you push that change, along with an appropriate comment.

John Darrington <jmd>
Group administrator
Sun 12 May 2024 06:49:14 AM UTC, comment #1: 

I did some further investigation and figured out that MacOS posts the html version with the mime type "text/html" but on MacOS this requires "public.html".  With some quickfix I added "public.html" as additional advertised type here:


and then I can paste in Libreoffice with "html" which is better rendered. When I have both "img" and "html" in the clipboard, then Libreoffice prefers the image as the default pasted. So the first thing would be to have text/html advertised correctly on MacOS.

The advertised "application/vnd.oasis.opendocument.text" is not considered by LibreOffice, not on Linux and not on MacOS.

MacOS uti <-> mimetype relation is described here: https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html

Friedrich Beckmann <beckmanf>
Group Member
Sat 10 Feb 2024 04:14:26 PM UTC, original submission:  

The copy&paste operation in the output view copies tables as text but not as image. The discussion of this topic is here:


The behaviour changed versus a previous release with this commit


which was made to copy&paste table data as editable data with libreoffice. I could reproduce the behaviour on MacOS. On MacOS the table data is only available as text (maybe UTF-8) also if I paste it in LibreOffice Calc. As Andreas mentioned the tables look o.k. if rendered with a fixed width font but this is not scalable for wide tables.

I did a test to also add the graphics to the clipboard. Then LibreOffice Calc on MacOS pastes the graphics instead of the text as default. Via "Paste Special" I can decide to paste the text which is also available in the clipboard.

The clipboard format handling depends on mime types and I have the impression that this does not work seamlessly for odt formats on MacOS.

Friedrich Beckmann <beckmanf>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jmd (Posted a comment)
  • -email is unavailable- added by beckmanf (Submitted the item)
  • -email is unavailable- added by beckmanf
  • -email is unavailable- added by beckmanf

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-06-02 beckmanf Attached File- Added clipboard-chart-aftergdkpatch.jpg, #56128
        Attached File- Added clipboard-table-aftergdkpatch.jpg, #56129
    2024-02-10 beckmanf Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-c54d.
    Corresponding source code