J2TextPrinter Known Problems

J2PanelPrinter 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 J2PanelPrinter

Text styles shifted left or right - Bug Parade 4724061 and Bug Parade 4352983
If you print a JPanel containing a JLabel or JTextPane with long lines of plain text with the occasional bold, italic, or underlined text, the styled text can wind up shifted left or right relative to where it should be. The result is either extra spaces or overlapping of characters and can be as much as several characters wide. The problem does not show up on the screen. The effect is dependent on the text that appears before the style change on the line. Style changes early in the line show the problem less. Style changes later in the line can shift left or right depending on the earlier characters. The effect is font-dependent, some fonts and sizes do better than others.

The problem is a result of a font metrics mismatch between the screen and the printer due to their differing resolutions. Depending on the characters involved, a given number of display pixels don't convert to an exact number of printer pixels, and the cummulative round-off error can build up to a large number of pixels, either too many or too few. When the style changes, Java sets the absolute printer position for the next run of text based on this calculation, and all the cumulative error shows up at once, resulting in either a gap or overlapping characters.

A workaround is to cause this repositioning to occur after every word or even after every character so that the error never gets too large. If the JLabel or JTextPane is defined using HTML, then every new HTML tag causes this repositioning to take place. A sequence such as <b></b> does nothing and so it can be inserted as often as desired to bring about this effect. The smallest sequence that appears to work and have no effect on the display is <a>. This is the hyperlink ("anchor") tag with no HREF or other subtags, so a closing </a> is not required. If you employ this technique after every character, you may discover that for certain fonts it is counter-productive after some characters (for example: l, m, n, i, ...), which would do better left alone. A further refinement in this case is to build a "kerning" table indicating which characters are OK to follow with <a> and which are not. The general idea is to place the repositionings where they are least noticeable, e.g., after whole words and after those characters whose width favors it.

Text clipped at right edge of JLabel or JTextPane - Bug Parade 4352983
Some JLabel or JTextPane instances with long lines will print with the rightmost character(s) partially clipped off. The problem does not occur on the screen. A workaround for the JLabel case is to pad your JLabel String with one or two extra spaces. The <a> tag technique described under "Text styles shifted left or right" also works.

Printing JPanel containing certain components throws IllegalStateException (JDK 1.4) - Bug Parade 4708924
Regression from JDK 1.3.1, fixed in JDK 1.4.1, broken in 1.4.2, fixed in 1.4.2_02
When Java tries to print (or print preview) certain components containing in a JPanel under JDK 1.4, it sometimes throws the exception:
java.lang.IllegalStateException: constrain(xywh) not supported for complex transform
This problem is similar to the problem of printing embedded components in a JTextPane described in the J2TextPrinter section. It only occurs in certain situations such as printing a JPanel that contains a scaled BufferedImage or a subclass of a Container containing another Component. This problem was fixed in JDK 1.4.1, broken again in 1.4.2, and fixed again in 1.4.2_02. The problem was a regression from JDK 1.3.1. It appears to be related to rescaling of certain components, either when print preview is at other than 100% scale, printing to a printer at a different scale, or when using SHRINK_TO_FIT or SHRINK_TO_WIDTH.