JDK-4758447 : 1.4 REGRESSION: Fonts won't print on HP 582C in JRE 1.4 but works in JRE 1.3.1
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.2_09
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-10-04
  • Updated: 2002-11-27
  • Resolved: 2002-11-27
Related Reports
Duplicate :  
Relates :  
Description
Name: jk109818			Date: 10/04/2002


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

java version "1.4.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_02-b02)
Java HotSpot(TM) Client VM (build 1.4.0_02-b02, mixed mode)

java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

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

EXTRA RELEVANT SYSTEM CONFIGURATION :
HP Deskjet 682C, HP Deskjet 540C, Epson Stylus Color 640

A DESCRIPTION OF THE PROBLEM :
Printing a component using the Java 1.2 API Printable and
Pageable interfaces and Graphics2D object worked under JRE
1.3.1 but doesn't under JRE 1.4.0_01,_02. The component
prints, but the text does not, unless the color is set to
Color.Blue or some variation of Blue. Using
java.awt.Color(0,0,255) for the text results in printed
text, blue if printed in color and black in B/W. As you
change the color closer to (0,0,0), the result is lighter,
until the result is no printed text. If there is a
background to the object, the text results as white shadow
on the background. All Green text, All Red text and All
Black text do not print. All Colors display properly on the
object on the screen, but do not print.
The problem occurs with a HP 682C, HP 540C and Epson 640
printers. A Canon C755 prints the text OK but seems to have
other problems with the bottom margin(not this specific bug).

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Create a class PrintableTable that extends JFrame
implements Printable, see source code below.
2.Run and print with HP 682C Inkjet printer. See results below.
3.Try changing the title text foreground to blue, then other
colors. Only blue prints in color or B/W.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Running this results in a Window that displays a table with
2 columns and 2 rows. The table has a header. There is a
title above the table and a button below the table. Text is
displayed in both the title and the table.
Press the button and the print dialogs display allowing the
selection of format and printer.
The resulting printout displays a white shadow of the
"Title" text and the "Column" and "Header" column headers
and no text in the table.
The resulting printout should print the text in the Title
label as well as the table header and cells.
If the title foreground is changed to blue, the text prints.
If the title foreground is changed to red, the text shadow
results.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
no error messages.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package test1;

import java.awt.*;
import java.awt.print.*;

public class PrintableTable extends javax.swing.JFrame implements Printable {
	Component c;

public PrintableTable() {
	super("Simple JTable Test");
	setSize(300,150);
	javax.swing.JPanel titlePanel = new javax.swing.JPanel(new FlowLayout());
	javax.swing.JLabel title = new javax.swing.JLabel("Title");
	titlePanel.add(title);
	javax.swing.JTable jt = new javax.swing.JTable (new String[][] {{"this", "is"},
{"a", "Test"}}, new String[] {"Column", "Header"});
	javax.swing.JScrollPane jsp = new javax.swing.JScrollPane(jt);
	javax.swing.JPanel panel = new javax.swing.JPanel(new BorderLayout());
	panel.setBackground(Color.white);
	panel.add(titlePanel, BorderLayout.NORTH);
	panel.add(jsp, BorderLayout.CENTER);
	getContentPane().add(panel, BorderLayout.CENTER);
	this.c = panel;
	javax.swing.JButton button = new javax.swing.JButton("Print");
	getContentPane().add(button,BorderLayout.SOUTH);
	button.addActionListener(new java.awt.event.ActionListener() {
		public void actionPerformed (java.awt.event.ActionEvent e) {
			try {
				print();
			}
			catch (java.lang.Throwable exc) {
				System.out.println("Printer Exception");
			}
		}
	});
	
}

public static void main(String[] args) {
	PrintableTable pt = new PrintableTable();
	pt.setVisible(true);
}

public void print() throws java.awt.print.PrinterException {
	PrinterJob job = PrinterJob.getPrinterJob();
	PageFormat format = job.pageDialog(job.defaultPage());
	job.setPrintable(this,format);
	if (job.printDialog())
		job.print();
}
	
public int print(Graphics graphics, PageFormat pageFormat, int pageIndex) throws
PrinterException {
	if (pageIndex > 0)
		return Printable.NO_SUCH_PAGE;
	Graphics2D g2 = (Graphics2D) graphics;
	g2.translate(pageFormat.getImageableX(),pageFormat.getImageableY());
	c.paint(g2);
	return Printable.PAGE_EXISTS;
}
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Print in blue text only. But no way to determine printer.
Since the in my application, the table column renderer is
used both for the user interface and printing of table, it
is unacceptable. This impacts the user interface use of
color for distinguishing data states.

Release Regression From : 1.3.1
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 164896) 
======================================================================

Comments
EVALUATION 4733565 was closed as a dup of 4507322, which was in turn closed as a dup of 4886732: AffineTransformOp does not work properly for some of the rendering hints that bug is in fact arguably a dup of 5051527 : Faster, more direct software transformation of images which is what appears to have resolved 4886732. Now for a bit of explanation of all this : The test program here is printing an image because it didn't disable the swing backbuffer. The image printing code does some calculations with the image scaling to the device and on most printers where the scale from 2D's 72 dpi to device scale (eg 600 dpi) is not an integral (eg its 600/72 == 8.1667 for 600 dpi) then a small floating point error is sufficient for a drawImage call to be under a tranform with a scale something like (1.0000001, 1.0000001) on JDK 1.4.2 that is sufficient to invoke the broken code as described in 4886732 In JDK 1.5 the Hava 2D image transforming code was enhanced to spot scales so close to an integral value and just map them to integral values and invoke an optimised loop which works fine. That was this fix : 4990624: Image pipeline heuristics for choosing transform code are too strict In JDK 6 (mustang) the more complete fix [5051527] seems to have resolved the issue even for scales not close to an integral value. So in 1.4.2, a simple fix for the printing code would be to apply a similar rounding of (1.0000001, 1.0000001)-> (1, 1)in the printing code, before handing the transform to the image code. This would avoid the problem in all the common cases as already is happening in 1.5. Also the way the image printing code divided out the scale it would always end up with values close to but not quite exactly 1.0 So there's no particular point in applying the same fix to 1.5 since it already handles this in the image code, and in 1.6 there's the additional fix as of b10. That will come into play in cases where 1.6 image printing has been updated to leave scales other than the device scale in the transform. So in summary a printing workaround fix is needed in 1.4.2 only. Also from the above 00/72 == 8.1667 example it should be apparent that if you are lucky enough to have a printer that's say 360 dpi or 720 dpi you won't trip over this bug in 1.4.2 since 360/72 == 5 and 720/72==10 and no f.p error is introduced.
16-03-2006

EVALUATION ================================== Looks like regression is caused by fixing 4258020. Related to the bitmap header structure which we pass to StretchDIBits. In Win2K, we ought to use the extended version for added functionality. ###@###.### 2002-10-29 ====================================== Fails using 16-bit depth color. Closing as dup of 4733565. ###@###.### 2002-11-27 ====================================
29-10-2002