Feature request: Make “-Edit/Export Clipboard to System” a scriptable item

[Mi605]

I need to transfer images created and edited in mtPaint to system clipboard for further processing in e.g. vector graphics program (incscape) or pdf annotation application (xournal).

While this works properly when performing all the needed steps manually in mtPaint, It fails when trying to automatise it using the --cmd script.

The intended workflow is (to be scripted): — have an image file, format doesn't care — open it with mtPaint (— do some image manipulations) — select all — copy to clipboard — export the raster data to system clipboard — close mtPaint

And in the other application (manually): — paste the raster data by using ctrl+v

An example (reduced to the core issue, omiting all intended mtPaint image manipulation) might be:

mtpaint --cmd -file/op='test.jpg' -selection/all -edit/copy -edit/'Export clipboard to System'

which comes up only with the error message '-edit/Export clipboard to System' matches a non-scriptable item

The default workaround for this kind of problem on linux (saving to a file instead again, using xclip to read this file into system clipboard,) fails here, since this will read the full, format specific file content rather then the true rasterdata included, which is present when directly copying and exporting from within mtPaint. There seems no linux console tool able to read a graphics file raster data content into clipboard the same way mtPaint does. (Some researching brought up, that there exists a tool called impbcopy, but this is an apple tool not running on default linux on a PC). So I have to export directly from mtPaint to system clipboard rather than store to file first.

Any ideas?

[wjaguar]

Clipboard in *nix is managed by X, so no accessing it in the commandline mode anyway. However, I think in the GUI mode those menu items can be allowed to be scriptable, But either way, any clipboard image in X IS a regular file, so I fail to understand how there arises a difference of "the full, format specific file content rather then the true rasterdata". An exported clipboard is nothing but a plain old PNG, possibly with alpha, its being in-memory makes no difference as to the format or contents. If your clipboard is some part of the image, then either do a crop instead of a copy, or create new image from clipboard, prior to saving the result to a PNG. If your clipboard has a clipboard mask (from a polygon or such), then create a new image from clipboard, convert selection to alpha, and save THAT to a PNG: "-f/new=clip -c/new type=alpha state=sel -f/as=clip.png form=png"

[Mi605]

Yes, this is about GUI mode, running the commands and scripts from within a terminal emulator window like roxterm or whatever.

Do I read you correctly, the content of the system clipboard mtpaint exports is exactly same format as what is being written to file when saving in png format? If so, then reading the saved png file into clipboard by

xclip -selection clipboard -t "image/png" < "clip.png"

should result in the identic clipboard content, as you say. Nevertheless, when exporting from mtPaint to system clipboard, pasting to e.g. xournal works flawlessly, while when going via true saved png and reading the file back into clipboard this fails, regardless of png compression level. (btw, some other programs apart from xournal, incscape etc. accept this method). So there must be a difference which causes some programs to fail here.

Testing cenary: — Open or create an image file in mtpaint — ctrl+a — ctrl+c — export to system clipboard

— open or create new file in xournal, — ctrl+v everything fine, the copied content is present as expected.

But: — Open or create an image file in mtpaint — Save as png — transfer file into clipboard (xclip -selection clipboard -t "image/png" < "clip.png")

— open or create new file in xournal, — ctrl+v nothing happens at all. (While in some other programs this works, sometimes depending on which compression level you choose while saving the file from mtPaint)

This test proves there must be a difference in content of clipboard following the two paths.

Is there a special setting mtPaint uses to generate the clipboard content?

After extensive testing with multiple ways of saving I found the following: My original assumption the content of clipboard was some kind of plain raster bitmap when exported by mtPaint (I had guessed it was something like PAM format) has turned out to be wrong, it actually looks like a png. Can you confirm mtPaint uses compression level 1 for export to clipboard? Which other settings are used?

A bitwise comparison after piping the content from mtPaint exported system clipboard to file by xclip -selection clipboard -o -t image/png > cliptest.png shows no differences to the file saved directly from mtPaint to png format compression level 1, transparency -1, they are byte identical.

Nevertheless, the one way it is pastable, the other way refuses, so there still is a difference.

Further researching turned up the following difference, may be this is of importance:

$ xclip -selection clipboard -t "image/png" < "test.png"
$ xclip -selection clipboard -o -t TARGETS
TARGETS
image/png

or:

$ xclip -selection clipboard -t < "test.png"
$ xclip -selection clipboard -o -t TARGETS
TARGETS
UTF8_STRING

while when exporting the content directly from mtpaint to clipboard I get the following result:

$ xclip -selection clipboard -o -t TARGETS
TIMESTAMP
TARGETS
MULTIPLE
application/x-mtpaint-pmm
application/x-mtpaint-clipboard
image/png
image/bmp
image/x-bmp
image/x-MS-bmp
image/tiff
PIXMAP
BITMAP

And from this I get different output, depending on which of the listed possible targets is piped to a file.

So, the question narrows down to what is mtPaint actually sending to clipboard along with the png file when exporting, so it is understood properly by other programs? Is there a special target I have to file into xclip to mimic the true clipboard export from mtpaint? Or does it export a bunch of formats to clipboard to make other programs happy?

[wjaguar]

First, X clipboard does NOT have ANY contents, ever (unless a clipboard manager copies it and keeps it, which is a Bad Idea to allow for images). The paste-receiver requests "TARGETS" from the clipboard-owning program, chooses the format it understands best, requests it, and the owner prepares it and sends it (therefore, if you close the clipboard-owning program, its clipboard image is lost). In mtPaint, the preparing is done by exact same code as saving, with the only differences being, it is in-memory, and PNG/BMP/TIFF do not get any extra channels beyond alpha (selection goes into alpha), with indexed with alpha/selection converted to RGB, and yes, PNGs get compression level 1 (and TIFF, no compression at all).

As to Xournal: http://xournal.sourceforge.net/manual.html "To insert a new image (from a file on disk), click at the location where the upper-left corner is to be located. A file selection dialog box pops up. Alternatively, images can be pasted directly from the clipboard (without having to select the image tool). In both cases, the newly inserted image is selected, and can be easily moved or resized as with any selection." What, exactly, is the reason to torture the clipboard? :) Either way, if Xournal can insert some file as a file, it should be able to insert the same file from clipboard too.