Updated the content parser, fonts and graphic shapes stack to handle text rendering modes, 4, 5, 6 and seven with regards to glyph outline clipping. Also updated the pro font library as well.

The overall clipping effect is not not anti-aliased which makes for a less then perfect cutout effect. If time permits I try and circle back to see if there is better way to apply the clip.

I managed to cut in a new object GlyphOutlineClip that is updated as the Text block is processed and add support for font modes, 4, 5, 6 and 7. The cut out effect renders correctly but it's a bit slow and jagged, I'll need to see if there is some way to improve both of these issue. I still have to apply the changes to the OS font handling.

The file in the form posting above as well as the attached file now render however PDF-422 is still not correctly rendering.

Another users experiencing the same clipping issue.

http://jforum.icesoft.org/JForum/posts/list/0/20892.page#73736

The last issue related to this document is not related to marked content but actually to the text rendering mode 7 or add text to path for clipping. I've looked back through svn and cvs and it appears that we never support this text rendering mode. According to the spec we are to keep the outlines of any glyph that uses this mode. And when the ET token is encountered we apply the summation of the outlines as the current clip. In theory this is quite a simple task but implementing it has proven more difficult.

The rendering core uses affine transforms to move the plotter needle if you will before each shape is painted. So when the ET token is encounter the needle has moved to the end of the text line at which point all the outlines are drawn at the same location. My first attempt at solving the problem was implemented in the contentParser but after quite a bit of analysis outline clipping can't be done here as we need to know the exact location of where the outline is to be drawn and we don't know that until the shapes.paint() is called.

So I added a new new object Marker OutlineTextClip which stores the outline of a textSprite and is added to the shapes vector. Once a ET is encounted a new shapes command TextOutlineClip is put on the stack. The idea being that when the pages is painted the text outlines can be added and then used as a clip. This is working but for for some reason can can't seem to translate the x,y of the outline as the text is written out. Still have to figure out how to correctly transform an area to the correct location.

I have fixes for one and three.

The function error is technically a malformed PDF, the function definition is lacking a bounds attribute which is need to properly execute the function. There isn't anything in the spec to saw what should be done when this error occurs. I've touched up to code so that it will return a valid set of numbers instead of null. The strange part about the problem is that it it doesn't affect the visible appearance of the page. So I'm guessing the PDF encoder has inadvertently left some junk in and my change is more of a work around.

The colour error for 3 is related to the Seperation colour space. This colour space is a bit odd but after reviewing the spec seemed to following the rules but the generated colour was till wrong. I did find a note in the latest PDF specification that that stated regardless of additive or subtractive device, if the named colour could be represented in the colour space it should be used as is and the alternative colour and tint should be avoided. I made a small modification so that if black, red, green or blue was detected for colour name then we would just use it verbatim. I'll have to see if anything strange comes out of QA as a result of the change.

1.) There is an error with the image decode and conversion to RGB, error coming out of the type3 function handling.
2.) This appears to a be a clipping issue that we've seen quite a bit of as of late.
3. ) Either a parser error or related to the colour issue in 1.

The PDF in question is very odd, having no mentioned of source producer. I think all the issue can be solve but will take some time to figure out all the root causes. My hunch is that this PDF isn't well formed.

Log feedback during review of the attached PDF in the ICEpdf Viewer:

org.icepdf.core.pobjects.Name convertHexChars
WARNING: Error parsing hexadecimal characters.