Selection owners can (and often do) provide multiple targets. This can be seen by using xclip -T after a copy. For example, a JPEG image copied in Firefox may be available as "image/png", "image/jpeg", and "text/html". The PNG would be dynamically generated only upon request. The HTML target is the code (including the filename and some meta data) that was used to embed the image.
While I don't expect xclip to know how to convert images from one format to another, it would be nice if multiple targets were supported so that a user could specify them as multiple files, if needed.
For example, at one point (and possibly still), Google's mail client could only embed pasted images that were available as "image/png". A person who wanted to do a copy of both a JPEG and PNG version using xclip could perhaps do something like this:
The main advantage of implementing multiple targets as separate files is it wouldn't require xclip to have any knowledge of formats. It would be wasteful of memory and CPU, but that's probably not a big deal as it only would occur when the user requests it.
[If efficiency is necessary, it may be possible for xclip to open but not read files until they are required. Presuming a typical UNIX filesystem, even if the file is later deleted, xclip will still be able to read the data. Of course, this runs the risk of other subtle problems, such as the data being changed after xclip has started. But, hopefully such efficiency will not be necessary.]
Selection owners can (and often do) provide multiple targets. This can be seen by using
xclip -T
after a copy. For example, a JPEG image copied in Firefox may be available as "image/png", "image/jpeg", and "text/html". The PNG would be dynamically generated only upon request. The HTML target is the code (including the filename and some meta data) that was used to embed the image.While I don't expect xclip to know how to convert images from one format to another, it would be nice if multiple targets were supported so that a user could specify them as multiple files, if needed.
For example, at one point (and possibly still), Google's mail client could only embed pasted images that were available as "image/png". A person who wanted to do a copy of both a JPEG and PNG version using xclip could perhaps do something like this:
or, using process subtitution in bash:
The main advantage of implementing multiple targets as separate files is it wouldn't require xclip to have any knowledge of formats. It would be wasteful of memory and CPU, but that's probably not a big deal as it only would occur when the user requests it.
[If efficiency is necessary, it may be possible for xclip to open but not read files until they are required. Presuming a typical UNIX filesystem, even if the file is later deleted, xclip will still be able to read the data. Of course, this runs the risk of other subtle problems, such as the data being changed after xclip has started. But, hopefully such efficiency will not be necessary.]