JDK-4924298 : Prints some (complex) pages incompletely
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.3.1_04,1.4.2,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2003-09-17
  • Updated: 2006-04-20
  • Resolved: 2006-04-20
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
Name: jk109818			Date: 09/17/2003


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

and

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

FULL OS VERSION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
We have a rather complex data warehouse application which can print multi-form page layouts. Those layouts tend to become more and more complex. When those printouts are produced some (about 30 percent) of the pages are printed incompletely. This happens for different brands of printer, Postscript and non-postscript. The funny thing is that using FinePrint or PDFWriter to print indirectly solves the problem.

It is not a printer problem since the spool-file reproducibly stops drawing the page at the same place and reducing the resolution to save printer memory has no effect.

Recently, I've found a work-around which might give you a hint on the source of the problem: If I set a non-uniform scale or shear, then the problem seems to disappear for Postscript printers. At least one non-Postscript printer still shows the problem. It also stops more frequently when starting to print a string than with other graphical elements, although I've seen it happen before drawing a box.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Difficult to reproduce exactly. Our application would show the problem on 30 percent of all multi-form page layouts.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Complete printour
ACTUAL -
Some pages incompletely printed

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error message

REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
Now, works on Postscript printers by adding a g2.getTransform().scale(0.999999,1.0) transformation or a shear() call.

Using FinePrint or PDFWriter as the printer driver also works reproducibly.
(Incident Review ID: 200117) 
======================================================================
----------------------
 6308772 Description
----------------------
FULL PRODUCT VERSION :
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

FULL OS VERSION :
Microsoft Windows 2000 ver 5.00.2195 Service Pack 3

A DESCRIPTION OF THE PROBLEM :
When printing a JTable in landscape VM crashes; or partially prints; or print is missing or garbage.

This behavior occurs if I create my own Printable object and do painting myself in the print method or if I call the JTable print method.

The attached testcase should help in reproducing the bug.  It has 
crashed the VM several times.  I can't recall it ever printing all three pages
correctly.  You can control the print density by expanding the columns since
it automatically scales the print down.

The tests were performed on a HP LaserJet 8000 series printer connected 
to a 10Gb Ethernet network.  It is printing PostScript format.

As far as I know the problem does not occur when:
  - run as an Applet
  - portrait layout is used
  - the print is output to a file and printed w/ a utility

When I print to a file using the test program I get a lot of garbage.  This is the program I used to print the test file.

Perhaps there is a threading problem when rotating the image in 
landscape layout or a buffer issue or several errors.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: No

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Execute the attached test case

EXPECTED VERSUS ACTUAL BEHAVIOR :
The table object should print as it does on the screen.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Attached seperatly

---------- BEGIN SOURCE ----------

import java.util.*;
import java.net.*;
import java.awt.*;
import java.text.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.table.*;
import javax.print.*;
import javax.print.attribute.*;
import javax.print.attribute.standard.*;
import javax.print.event.*;

public class MainFrame extends JFrame implements ActionListener {
  JMenuBar menuBar;
  JMenu options;
	JMenuItem printAlloc;

  JTable testTab;
  TestModel allocModel = new TestModel();
  JTabbedPane tabbedPane = new JTabbedPane();

  public MainFrame () {
    super("Print Test");

    addWindowListener (new WindowAdapter() {
      public void windowClosing(WindowEvent e) {
				System.exit(0);
      }
    });

		testTab = new JTable();
		testTab.getTableHeader().setReorderingAllowed(false);
		testTab.setAutoResizeMode(JTable.AUTO_RESIZE_OFF);
		testTab.setPreferredScrollableViewportSize(new
Dimension(500, 70));
		testTab.setColumnSelectionAllowed(true);
		testTab.setCellSelectionEnabled(true);
    testTab.setModel(allocModel);
		
    JScrollPane jspan = new JScrollPane(testTab);
    jspan.getViewport().setPreferredSize(new Dimension(500, 300));

    //Create the scroll pane and add the table to it. 
    tabbedPane.addTab("Allocations", null, jspan, "Identify Current Allocation");
		
    menuBar = new JMenuBar();
    setJMenuBar(menuBar);

    JMenu printing = new JMenu("Printing");
    printAlloc = new JMenuItem("Print Allocations");
    printing.add(printAlloc);

    JMenu actions = new JMenu("Actions");
    actions.add(printing);
    menuBar.add(actions);

		printAlloc.addActionListener(this);

		Container cp = getContentPane();
		
		cp.setLayout(new GridLayout(1, 1)); 
    cp.add(tabbedPane);

    setBounds(20, 20, 700, 800);
    setVisible(true);
	}

	public void actionPerformed(ActionEvent ae) {
		MessageFormat header = new MessageFormat("Bug Testing");
	  Object [] arguments = {new Date(System.currentTimeMillis())};

		String result = MessageFormat.format("{0,date},",arguments);
		System.out.println("printing..");
		System.out.println(result);
    MessageFormat footer = new MessageFormat("result");		
		boolean showPrintDialog = true;
		boolean interactive = true;
		PrintRequestAttributeSet attr = new
HashPrintRequestAttributeSet();
		// set the page orientation
		attr.add(OrientationRequested.LANDSCAPE);
		try {
			System.out.println("printing..");
			testTab.print(JTable.PrintMode.FIT_WIDTH, header,
footer, showPrintDialog, attr, interactive);
			System.out.println("printing.. done");
		}
		catch(Exception e) {
			e.printStackTrace();
		}
	}

  public static void main (String[] args) {
		new MainFrame();
  }
}

class TestModel extends AbstractTableModel {
		
	String alpha =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

  public TestModel() {
    super();
  }
	
  public int getColumnCount() {
    return 15;
  }
 
  public int getRowCount() {
    return 400;
  }

  public Object getValueAt(int row, int col) {
		return(alpha);
  }

  public Class getColumnClass(int col) {
    try {
			return getValueAt(0, col).getClass();
    }
    catch (Exception e) {
      return "Test".getClass();
    }
  }

	public boolean isCellEditable(int row, int col) {
		return false;
	}

	public void setValueAt(Object value, int row, int col) {
	}
}
---------- END SOURCE ---------- 

REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
Must print portrate
*** (#1 of 1): 2005-08-09 22:21:50 PDT ###@###.###

Comments
EVALUATION At this point we've had lots of satisfactory testing that indicate that 6186524 : Swing Basher throws an expection(EXCEPTION_ACCESS_VIOLATION) in windows XP professional does indeed resolve this and other similar bugs, notably 6308772 : Landscape printing problem - VM crash or incomplete print 6394247 : Random VM crashes while printing closing as dup of 6186524 since that is already fixed. The fix will be backported to a 5.0 update release.
20-04-2006

WORK AROUND Use mustang (1.6). Also when printing if you use a physical font, eg "Arial", instead of "SansSerif", or "Times New Roman" instead of "Serif" you should be able to avoid the problem. However that may not be ideal for all apps as its much harder to be cross-platform.
06-04-2006

EVALUATION We believe this is related to the issues described in 6186524 : Swing Basher throws an expection(EXCEPTION_ACCESS_VIOLATION) in windows XP professional which is FIXED in mustang. The related problem there is that windows HFONTs and certain subclasses of Graphics were being allocated faster than they could be freed because they are freed in a finalize() method. We were seeing exhaustion of windows handles. There is an open bug on the font finalization issue: 6247526 : java.awt.Font should not be finalizable. HFONTs are attached to fonts using code that dates from JDK 1.0 and is used by AWT heavyweights (on windows native controls). Printing happens to leverage that code still. The 6186524 fix is a workaround to minimise the number of Font instances used inside the printing code. The fix was implemented in mustang build 33 and seems to cure this bug. It also cures the crashing bug seen in 6308772 (closed as a dup of this one) and we did observe using the test case for that bug that when it reproduced on 1.5 that the number of GDI Objects in use shot up. The reason 6308772 is much more reproducible and is fixed by 6186524 is that it specifically rotates the page (landscape mode). AwtFont native code does in fact try to cache and share HFONTs. However that cache excludes fonts which where there is a rotation or width scale. That case is only ever invoked by the printing code. Fixing the printing code to cache those cases at a higher level fixed that. One wrinkle is that there was one place in the printing code where we did not attempt to minimise the number of fonts since it was only used for a few instances. When the unrelated 4339577 was implemented it changed the way that Font.getFont(Map) worked to not use a cache. So there is some potential for continuing reproducibility of this issue in some cases, at least on some system configurations which can outrun finalization. Because of that and we now need to close that loop hole. However further research indicates that specific case isn't used for rendering so it always specifies that the font should be unrotated and unscaled so it is always eligible for HFONT cacheing in AwtFont. Thus this not in fact a problem although the code is still unnecessary. It should be noted that in general creating new Font instances is NOT any kind of burden and there should be no need for an application or the JRE to cache fonts. Swing apps for example would never use an HFONT resource as Swing text rendering uses a non-native and shared Font resource so its cheap, fast and consumes just one shared resource underlying many java.awt.Font instances. Internally to the JDK Font.getFont(Map) is used in just 3 places in classes that implement the java.awt.font.TextLayout class. The only case in which this is used in conjunction with HFONTs is internally in printing certain fonts and with certain APIs that would trigger TextLayout. So its not clear that Font.getFont(Map) needs to revert to a map. Its probably sufficient to fix the printing code. Also there is an intention to eliminate the usage in printing of the code path that uses these HFONTs. The current state of understanding of this bug is not as 100% certain as I would like it to be. Analysis of the caching of HFONTs as demonstrated by a test case supplied for this program seems to show that it actually gets a high level of sharing. However it also appears that sharing of the java.awt.Font objects fixes it and certainly exhaustion of windows handles was one of the problems seen in investigating 6186524 but it was subsidiary to OutofMemoryError. Maybe this is similar.
06-04-2006

WORK AROUND Use VM option: -Dsun.java2d.print.shapetext=true
31-08-2005

EVALUATION Cannot evaluate this without reproducible test case but can the submitter try disabling "Advanced Printer Features"? This seems to solve the problem as noted in JDC comments. If this works and so is printing to a file then I'm inclined to think that this is XP spooler issue. Marking incomplete. ###@###.### 2004-12-01 20:50:17 GMT
01-12-2004