Printing of AWT componenst is not working both with old and new Plug-in on IE6/IE7, FF2/FF3 and mozilla browsers. This regression got introduced in 6u10-b12. Everything worked fine till 6u10-b11. With the current build printing is working fine if applet contains Swing component or painting is done directly on Applet panel.

Steps to reproduce:
-----------
1) Install latest 6u10
2) Try to load any of the following applets
http://java.sun.com/products/plugin/1.5.0/demos/applets/ArcTest/example1.html
(this applet contains AWT Text fields and Buttons)
or 
http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/ALC/PrintThreadNew.html

3) Try to print applets using Browser File > Print menu option

If AWT components fails to print then bug is reproduced

Repeat all the above steps with old Plug-in 

Non-AWT applets(Printing should work fine applets listed below)
http://java.sun.com/products/plugin/1.5.0/demos/jfc/SwingSet2/SwingSet2.html
http://java.sun.com/products/plugin/1.5.0/demos/applets/Clock/example1.html
http://java.sun.com/products/plugin/1.5.0/demos/applets/SpreadSheet/example1.html
http://java.sun.com/products/plugin/1.5.0/demos/applets/BarChart/example1.html
Posted Date : 2008-06-26 02:57:48.0

N/A

Its not just applets. I'm seeing lots of problems in a standalone app using
test/java/awt/PrintJob/PrintComponentTest/PrintComponentTest.java

I suspect a z-ordering issue as WComponentPeer.createPrintedPixels() is
apparently returning some data.
Posted Date : 2008-06-26 23:52:44.0

This is a regression of the fix for 6648996 (Frame.printAll() invoked on a non-opaque window prints black background).

The problem is the type of the BufferedImage created in the WComponentPeer.print() method. It used to be BufferedImage.TYPE_INT_RGB, but with the fix for 6648996 it changed to BufferedImage.TYPE_INT_ARGB. W/o that change the non-opaque windows got printed with a black background instead of transparent background.

It seems that the problem is the createPrintedPixels() method which draws heavyweight components with alpha value of zero. That's why they probably do not get printed.
Posted Date : 2008-06-27 10:29:23.0

The AwtComponent::CreatePrintedPixels() function did not ever write the alpha component of the printed pixels. Hence, the alpha in the pixels array was always zero. It didn't cause problems before the fix for 6648996 because TYPE_INT_RGB kind of BufferedImage was used which obviously ignored the alpha color component (when using its setRGB() method). However, when using the TYPE_INT_ARGB type, the BufferedImage started to respect the alpha component. As all alpha components were zeros, no heavyweight content was printed.

The suggested fix resolves this issue manually filling the alpha color component when handling the WM_PRINT message for heavyweight components.
Posted Date : 2008-06-30 14:40:11.0