I've take a a really close look at this issue and it is related to how the PDF in question is encoded. The font bbox is [0,0, 1000, 1000] which appears to be incorrect when compared to the font's widths that average at 20 units.

When we do layout we depend on the Postscript as well as the font's glyph width. We use the bbox to optimize the drawing of the font glyph, if the font's bbox isn't in the current clip then we don't bother drawing it. In the viewer RI this work out OK as the view window clips is usually quite large, the size of the viewer itself and the incorrect bbox always intersects the view and thus we draw it. However when a PDF of this type is printed the print clip is quite small around 5x5 units. The print clip doesn't always intersect with the incorrectly aligned bbox and thus we don't draw the glyph.

This is the only sample that has an incorrectly encoded bbox, my other samples all draw the bbox correctly and seem to print without missing content. I incorrectly described the workaround for this issue. Make sure to enable clipping but make sure you set -Dorg.icepdf.core.text.optimized=false to disabled ICEpdf's text clip optimization.

Unfortuantely no new news on this one.

A customer has reported that the workaround of setting -Dorg.icepdf.core.text.optimized=false no longer works in 4.2. The text appears correctly in 4.1.4 but is garbled is 4.2. I cannot reproduce this issue on my Mac OSX 10.6.7 with Java 1.6.0_24 in either 4.1.4 or 4.2 or with Windows 7 and JDK 1.6.0_23. Is this a possible regression in certain environments?

There where no changes made to 4.2 around the property -Dorg.icepdf.core.text.optimized=false. The issue they are seeing is related to how widths are calculated for glyphs. I'll have to take a closer look to see if this is related to how the sz token is handled. .

Update the NFontType3 bbox logic to property scale and convert the box to correct space for painting. Text selection is now as predictable as acrobat.