This mail is a follow-up concerning a problem mentioned earlier on the mailing list.
Will Simpson wrote: > I have 'diffed' the two PDFs but have been unable to locate a /TYPE > entry problem. (Actually, I am not hugely knowledgable about PDFs - I am > hoping to learn a little more). If you open bad.pdf in a plain text editor (e.g. Wordpad), you'll see that object 29 is defined as follows: 29 0 obj<</Creator 943868237/ResFork 30 0 R/Type 1246774599>> This is a violation of one of the PDF syntax rules. Let me quote the PDF Reference (p59-60 about the Dictionary object): "The value of the Type or Subtype entry is always a name." You can recognize a name object in a PDF because it's always preceded by a '/'. For instance, in the above PDF snippet /Creator /ResFork and /Type are names, whereas 1246774599 is a number. That's what's getting you the class cast exception. I'm not sure what to do with this. Should iText be more tolerant for faulty PDFs? In some cases, it already is; in this case I don't know... br, Bruno ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://itext.ugent.be/itext-in-action/
