Problems copying diagrams as image to the clipboard

[codemanyak]

1. The menu item Edit => Copy PNG Image produces a useful transferrable image but does not preserve transparency (not at least under Windows), though the image creation uses the BufferedImage.TYPE_INT_ARGB type (such that you would expect the alpha channel is properly reflected). Hence, diagrams of types subroutine or includable will have black corners instead of transparent ones in image viewers and graphics editors or whatever insertion target environments. The JDK 11 now gives some clue, it produces the stacktrace of an otherwise silent IOException (that cannot be caught on the application level):
   java.io.IOException: Registered service providers failed to encode BufferedImage@19802e42: type = 2 DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=ff000000 IntegerInterleavedRaster: width = 154 height = 176 #Bands = 4 xOff = 0 yOff = 0 dataOffset[0] 0 to image/jpeg
   (Full stacktrace see attached file.)
   stacktrace_685.txt
   Apparently, the clipboard converts the image into JPG format instead of PNG as the menu item promises. As you would expect, the stacktrace vanishes if the image type BufferedImage.TYPE_INT_RGB is used to prepare the image for transfer. The visual result doesn't differ.
2. Unter Linux, it may be even worse - there is also an occurring stacktrace (see log file below), but apparently the clipboard won't contain any useable result afterwards. And in contrast to Windows, the copy action is not continued (the temporarily suppressed selection isn't restored, i.e. the action gets aborted.)
   err.log
   Well, I have to admit, my test environment uses a "somewhat" outdated system: openSUSE 13.2 (Harlequin) based on Linux kernel 3.16.6-2-desktop in a VirtualBox.
3. The attempt to copy an EMF image to the clipboard in Linux (same testing environment) also produces an error but no result:
   err_emf.log

[codemanyak]

Just checked it on a fresh debian 9 in a VM with Structorizer 3.29-03 on openjdk 8, and both 1 and 2 works great, 3 doesn't cause an error either, which means that the behaviour depends on the operating system and we have little chances to control what happens once the content is put to the clipboard. What I will have to check next is how openjdk-11 may react on a Linux machine.

[codemanyak]

So a simple temporary workaround could be to suppress the alpha channel in case the operating system is Windows...