JDK-6301927 : Java 1.4.2 does not print labels of buttons when using Windows XP Style
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1_04,1.4.2,5.0u4
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2005-07-26
  • Updated: 2010-05-08
  • Resolved: 2006-03-22
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.
JDK 6
6 b77Fixed
Related Reports
Duplicate :  
JDK-4909439 - Printing of translucent images is at image resolution, not printer resolution.
Relates :  
JDK-5106661 - XP L&F does not work on Windows Vista (Longhorn) - needs to use uxtheme api
Description
When printing a frame using J2SE 1.4.2 on Windows XP Style, the labels of all buttons are blank.
Everything else in the frame prints correctly (textfields, textareas, combo boxes, etc.)
This was working on JRE 1.4.1.x, but since 1.4.2.x, the problem started to happen.
Now they are working with 1.5 and the problem still exists. 

STEPS TO REPRODUCE:
1. Launch application in Windows configured with XP Style: "java
MenuDemo"
2. Select to print using menu item.
3. It takes some time to display the Print Dialog

This problem does not happen if using Windows Classic appearance.

A reproducible testcase can be found in:
/net/swampscott.east/space/share/CA/JDK.1.5.zip
Comments
EVALUATION This also fixed 4909439: Printing of translucent images is at image resolution, not printer resolution. as we create an image of higher resolution.
02-03-2006
EVALUATION The most immediate cause of the problem here is that the printing code was attempting to be conservative on memory when drawing a scaled translucent image (as used by Swing's Windows L&F on 1.4 and 1.5) Translucent images are drawn in a subsequent redraw "pass" using cached information. The printing code scales down such images to leave simple scaling to GDI and handles other transforms on the smaller image. Due to the extreme scaling requested by Swing (44x) and then the scale to device (eg 72->360 dpi) the scaled down image was too small to properly render the text label! There were also some quality problems even in cases which were superficially OK. In addition the test applied an additional graphics transform to make the rendering scale up to fit the page. This pointed out that the printing code was incorrectly setting the wrong initial transform for the redraw. Fixing these issues still showed intertwined problems even with printing opaque images. For most implied flip/rotate transforms of a drawImage call, the calculation was just wrong in either determining it was an empty src or dest. The clip was also calculated incorrectly. All of these problems go back to 1.2.2 or 1.3 (!) An important part of this fix is a comprehensive test for opaque and translucent images under a variety of transform conditions, such as drawImage scaling parameters which imply a flip and shears, rotations, scaling up and scaling down (for a large image to a small destination) to ensure correct registration of the image and appropriate quality. The fix for this corrects numerous problems and results in generally much higher quality. The cost is increased intermediate storage and larger spool files. The cost is however commensurate with the content and does not impact the most typical case: where some area of a non-translucent image is scaled to the device.
22-02-2006
EVALUATION I have no idea why this bounced around. It is almost certainly a long standing bug in the 2D printing implementation and the fact that it went away in some build is very probably (as noted) that Swing simply stopped triggering the bug in the original test case. At this point however, since it isn't easily reproducible in mustang we can defer it to a later release.
08-12-2005
EVALUATION I have added a modified test program. This has a custom component which duplicates the drawing that the real XP JButton would do. This will make it easier to play with drawing settings. It also shows that the bug affects applications that run under Metal as well as the XP look and feel.
08-12-2005
EVALUATION The relevant method which is corrupting the drawing surface is the paint9() method on line 656 of the com.sun.java.swing.plaf.windows.XPStyle class. In particular the drawing commands beginning on line 684 which use the extended Graphics.drawImage() method to draw scaled subsections of the image.
08-12-2005
EVALUATION My research indicates that this is some sort of strange 2D bug/side-effect. The effective DPI of the drawing surface is being changed some how during the drawing of the background images of XP JButtons. The XP buttons use an image extracted from windows to draw the button backgrounds. The image is sliced into nine pieces and each piece is individualy stretched, positioned, and painted using Graphics.drawImage() calls. Some of these calls are affecting the drawing surface in such a way that drawing commands issued afterwards produce bad results: text either disappears or draws in black, lines are draw with super low resolution and are blocky. I have attached a simplifed test program which has two JButtons, one to start the printing and one to demonstrate the effect of lines getting corrupted. I will transfer this bug to the 2D team and see what they think. - Joshua
08-12-2005
EVALUATION Needs to be fixed for 5.0 update.
09-09-2005
EVALUATION Not reproducible in 6.0. Probably fixed by rewrite of XP style handling for CR 5106661.
11-08-2005
EVALUATION This is already fixed by swing's mustang putback on 11/30/04. Assigning to swing for evaluation and for closing this bug.
10-08-2005