J2TablePrinter Known Problems

J2TablePrinter known problems

The Java 2 printing model was new in JDK 1.2 and there were a large number of problems there were not fixed until the JDK 1.3 release. More problems were fixed in JDK 1.4, which also added some important new features. For these reason, the use of JDK 1.4 or later, and preferably the current JDK, is strongly recommended. This section documents problems present in Java that can impact your use of J2PrinterWorks.

Known Java problems affecting J2TablePrinter

Partially printed pages on some printers for certain JTables - see Bug Parade 4970112
Fixed in JDK 1.5?
Certain JTables printed on some printers will sometimes partially print pages. The gridlines may print, but not all the rows of content, and generally the overall outline and the headers and footers are missing. Sometime one or two pages are affected and the rest are OK, but sometimes whole pages are omitted or the rest of the document doesn't print. The problem is intermittant with different output when printing is repeated. The problem seems to occur primarily when printing JTables with custom cell renderers (images, etc.), when printing landscape, when the JTable is many pages long, when a very wide JTable is scaled down to one page wide, or when printing n-up for large n. The problem does not show up in print preview and only occurs for actual printing. The problem only seems to occur for some printers. The problem also does not seem to occur when printing to a Postscript file. We believe the problem is associated with insufficient printer memory and/or OS print driver memory. The problem appears to have been fixed in JDK 1.5.0.

Borders don't work right for JTable - see Bug Parade 4307724 and Bug Parade 4222732
The Java Borders capability does not work properly for JTable. Instead of drawing the border around the outside of the JTable, the border overlaps the top, bottom, left, and right edges of the JTable. Since this is true for the JTable as displayed, J2TablePrinter can only print the same incorrect rendering. A workaround is to put your JTable inside a JPanel, use setBorder on your JPanel, and print with J2PanelPrinter. However, the result is acceptable only if your JTable is smaller than a page, since J2PanelPrinter can only paginate the JTable on pixel (not table row) boundaries. Another alternative you might find useful is to call the method J2TablePrinter.setOutsideLines(true), which will set a one pixel wide line surrounding any JTable.

Gridlines may be dropped when scaling
The Java2D system fails to display some or all of the hairline gridlines when the scaling factors set to less than 1.0 (minification). This occurs most often in the print preview dialog where the default printPreviewScaling is 0.5. It may also happen in the printed output if the print scaling factor is set to less than 1.0, depending on the scaling factor and the resolution of the printer, but this occurs less often since the printer generally has higher resolution than the display. Workaround: always use scale of 1.0.

JTable won't print using custom Look & Feel
Some publicly available alternative Look & Feel implementations (e.g., Kunststoff) will display correctly but are unable to print correctly. The Macintosh Look & Feel provided by Apple in its JDK 1.3.1 also has this problem (the Aqua Look & Feel used by Apple in JDK 1.4.1 and 1.4.2 is fine).   These problems are generally caused by the fact that the particular Look & Feel can't produce the JTable headers at the higher printing resolutions required. You can confirm this by setting tablePrinter.setColumnHeaderPrinting(J2TablePrinter.NO_PAGES) and seeing if you can now print your JTable without problems. The "Metal" Look and Feel provided in Java always prints correctly, so a solution to the above problems is to call either:
    UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
or
    UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
Likewise, the Motif Look & Feel provided in Java also works correctly, which you get by calling
    UIManager.setLookAndFeel("com.sun.java.swing.plaf.motif.MotifLookAndFeel");

If you want your application to use the custom Look & Feel for display, you can still print using a non-custom Look & Feel for just your JTable, or even just for a second copy of your JTable used only for printing. In turns out there is no MetalTableUI or MetalTableHeaderUI defined in Java, but there is a BasicTableHeaderUI that will print correctly, so you can use:
    table.getTableHeader().setUI(new javax.swing.plaf.basic.BasicTableHeaderUI());

Printing is slow for tables with images (JDK 1.2.x)
Improved in JDK 1.3, fixed in JDK 1.4
The use of images in cells or custom cell renderers that use the Java drawImage() method will greatly slow things down. This is due to major performance problems in JDK 1.2.2 (see Bug Parade 4185726) which makes printing of pages containing any images many times slower than normal, even if just one small image is present. The J2TablePrinter background printing thread feature is a great help in overcoming this problem for interactive (client) applications.

Black backgrounds when printing transparent GIFs under Windows NT (JDK 1.2 and JDK 1.3beta)
Fixed in JDK 1.3
Under Windows NT, GIF images with transparent backgrounds print incorrectly with black instead of transparent backgrounds due to a known Java bug (see Bug Parade 4175560), despite the fact that they display correctly. Under Windows 95 and Solaris, transparent GIFs display and print correctly. There are two workarounds for this: 1) make your GIFs with white non-transparent backgrounds or 2) make your GIFs with white backgrounds, specify white as your transparent color, and change non-transparent white pixels in your icon to near-white so they aren't transparent when displayed.

JTable with an empty cell won't print (JDK 1.2.x)
Fixed in JDK 1.3
Under JDK 1.2.2, if your JTable has an empty cell (a cell containing the empty string ""), Java will throw an exception at that point in printing your table. This bug is described in Bug Parade 4138921. A workaround is to replace the empty strings with a single space. If a single space has a meaning different than an empty string in your application, you can convert to spaces just prior to printing and convert back (or maintain a second JTable just for printing).

Printing of JCheckBox doesn't work (JDK 1.2.x)
Fixed in JDK 1.3
Due to a bug in JDK 1.2.2 (see Bug Parade 4202282), any JTable which uses a JCheckBox for rendering a boolean-valued cell will not print (even though it will display correctly in your application and in J2TablePrinter's print preview). The Bug Parade bug reports contain some workarounds for this problem. The J2TablePrinterTestApplication source code example includes code for two other workarounds, including 1) the use of images to display the true/false boolean values and 2) simply using text.

Table row and column sizes different between JDK 1.2 and later JDKs
Fixed in JDK 1.3
Beginning with JDK 1.3 beta (see Bug Parade 4303458), Sun changed the drawing size of JTable rows and columns. In JDK 1.2, the width of each cell was drawn with the size getColumn().getWidth() + intercellSpacing().width, whereas in JDK 1.3, the drawing width is getColumn().getWidth() which includes the intercellSpacing().width. Likewise, in JDK 1.2, the height of each cell was drawn with the size getRowHeight() + intercellSpacing().height, whereas in JDK 1.3, the drawing height is getRowHeight() which includes the intercellSpacing().height. The result is that rows and columns are slightly smaller under JDK 1.3beta and JDK 1.3 than they were in JDK 1.2 for a given set of specified sizes. J2PrinterWorks detects these differences and will print and paginate correctly on JDK 1.2.2, JDK 1.3beta, and JDK 1.3final.

Printing slow if JTable.setDoubleBuffering(true) (JDK 1.2.x)
Fixed in JDK 1.3
Under JDK 1.2, setting your JTable double buffering property to true slows down printing by about 6X. Not only did JDK 1.3 fix this problem, but JDK 1.3 printing is about 2X faster than JDK 1.2 printing even with JTable.setDoubleBuffering(false).