Nope, I'm afraid I missed this bit of information. The code I wrote just ignores exactly one whitespace character after ID. To produce a fix for special cases of ASCIIHexDecode and ASCII85Decode, I would think PdfContentsTokenizer has to include an additional state/flag indicating whether these encodings are used for inline image data; and of course ReadInlineImgData() should be changed accordingly.
On 21 Jul 2009, at 04:33, Craig Ringer wrote: > On Mon, 2009-07-20 at 20:30 +0100, Thach Tran wrote: > >> some feedbacks if that's ok. About using my sample PDF as a test >> case, >> I'm totally fine with it. I know it takes a bit of effort to find/ >> generate a PDF contains inline image these day :-) > > Hmm. The spec does say: > > "Unless the image uses ASCIIHexDecode or ASCII85Decode as one of its > filters, the ID operator should be followed by a single white-space > character, and the next character is interpreted as the first byte of > image data." > > Presumably it's expected that if the image does use one of those > encodings, additional whitespace is ignored, so your code should still > be fine. > > Sound right? > > -- > Craig Ringer > ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
