Likely a resource loading issue like PDF-129.

It appears that this issue effect all type 3 fonts. The print banding doesn't seem to do well with the small glyph images generated by the type3 fonts. The fonts are present but have been shrunk significantly. I tried turning off image scaling but that didn't seem to change anything.

I'll have to revisit this issue later as it is likely a Java Print issue.

After fixing a tranform bug with xform objects intersection with the clip this issue seems to reproduceable with the default ri viewer. Likely a similar spacial but is present in the type3 glyph content paths.

It appears this is a bounding issue for the type three fonts used in the filed. For some reason when I paint the bounds they aren't even close to the glyphs that are painted. During printing the clip is usually pretty tight which would explain why almost no glyphs show up when printing. I'll have to debug this further to see what up with the bounds.

Really having a hard time with this one, can't seem to find the cause and beginning to think it might be malformed. The max bounds of the fonts are not correctly assigned which leads to some glyphs being trimmed by the print banding clips. However each glyph has a clip defined that seems to be responsible for just about every glyph to be cut during the print.

If it would be malformed I couldn´t understand why the pdf displays correct on screen....

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.