JDK-4720930 : Copy/Paste images from outside apps should support transparency
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-07-25
  • Updated: 2002-10-11
  • Resolved: 2002-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4638448 - Clipboard Fixes and Enhancements
Description

Name: jk109818			Date: 07/25/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-
b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :Microsoft Windows 2000 [Version
5.00.2195]


A DESCRIPTION OF THE PROBLEM :
Java 1.4 now supports copy/paste of images from outside apps via
Transferable and DataFlavor.imageFlavor. However calling
getTransferData(DataFlavor.imageFlavor) results in a BufferedImage
object that does not contain alpha data:

BufferedImage@444319:
type = 1 DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=0
IntegerInterleavedRaster: width = 80 height = 50 #Bands = 3 xOff = 0 yOff = 0
dataOffset[0] 0

The means that if, for example a user copies a
transparent gif from their browser and pastes it into a java app, the
resulting image will not contain the alpha data, and I my testing, the
transparent pixels are black.

This shortcoming seriously
undermines any claim of image copy/paste that could be made for a java
application.

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 158695) 
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b03 VERIFIED IN: mantis
24-08-2004
PUBLIC COMMENTS .
24-08-2004
SUGGESTED FIX Name: agR10216 Date: 09/04/2002 Add 2 methods to the DataTransferer class: standardImageBytesOrStreamToImage() and imageToStandardBytes(). These methods convert between java.awt.Image and some standard image format (PNG, JFIF) by means of javax.imageio's registered service providers. Move convertion code from MDataTransferer's platformImageBytesOrStreamToImage() and imageToPlatformBytes() to these DataTransferer's methods. Call these Datatransferer's methods in WDatatransferer and MDataTransferer's platformImageBytesOrStreamToImage() and imageToPlatformBytes(), if the image format is PNG or JFIF. Add mappings for PNG and JFIF to the flavormap.properties files. ###@###.### 2002-09-03 ======================================================================
03-09-2002
WORK AROUND Name: agR10216 Date: 09/04/2002 Try to use another format(data flavor) to transfer an image. For example, if you copy (or drag) an image from Internet Explorer 5, 6, the browser exports the image in CF_DIB, as well as in CF_HDROP. CF_DIB uses BITMAPINFOHEADER. It does not contain any information about alpha channel. CF_HDROP matches DataFlavor.javaFileListFlavor. You can get File via DataFlavor.javaFileListFlavor and create Image. ###@###.### 2002-08-23 ======================================================================
23-08-2002
EVALUATION Name: agR10216 Date: 09/04/2002 I reproduced the bug with the build 1.4.2-beta-b01. Currently Java datatransfer subsystem supports the following Windows standard clipboard formats: CF_DIB, CF_ENHMETAFILE, CF_METAFILEPICT. There are no other standard clipboard formats for image transfer that are widely used by Windows applications. Many Windows application (e.g. Word 2000, InternetExplorer 5, 6) export data in CF_DIB format with a bitmap header prior to version 4. DIBs support transparency only via the v4 and v5 headers. Some applications (e.g. Word 2000) do not respect the v4 and v5 headers. So Java should use the old bitmap header without transparency support for CF_DIB. We could use a hack to transfer transparent images between 2 Java applications. BITMAPINFO.bmiColors contains an array of RGBQUAD. MSDN says that RGBQUAD.rgbReserved must be zero, but we could use meaningful RGBQUAD.rgbReserved for alpha value. We will not do it because it may confuse some other applications. CF_ENHMETAFILE and CF_METAFILEPICT contain enhanced metafile and Windows metafile respectively. Metafiles are simply stored GDI functions. There is no special support for transparency there. In order to support transparency for these formats we need to convert a metafile to the corresponding ARGB array. We use a bitmap for this purpose. But when a metafile is played on a bitmap metafile's GDI functions do not honor alpha value and we get fully transparent image. So those 3 formats are not suitable for transfer of transparent images. We will implement image transfer in PNG and JFIF formats. Many windows applications use these formats. We will make PNG format preferable, so that 2 Java applications will be able to exchange with transparent images properly. ###@###.### 2002-08-23 ======================================================================
23-08-2002