4 Replies Latest reply on Nov 11, 2010 2:09 PM by bleclerc

    Image XObject using /F file specification


      We are having a problem where instead of the stream data being on the Image XObject itself, we want to use a stream that is an attached file (we are manually writing the pdf file at this point using internal tools).  Inevitably, it keeps trying to get that file from the disk and failing. 


      This same file specification we are using as the /F property on the XObject dictionary is the same one in the as we have as an entry in the EmbeddedFiles name tree, and the file does appear appropriately in the attachments list.  The file spec includes all the correct /F filename and /EF<</F reference>> to the actual data stream. 


      The XObject dictionary still has a zero byte stream associated with it, and the /Length property set to 0.  And we're using raw RGB values, so no filter (/Filter or /FFilter) needs to be specified.


      The error we keep getting is "This file cannot be found" (fileErrFNF).  If we extract the file, then we get a different error of "You do not have access to this file" (fileErrPerm), unless supposedly, you are running Acrobat Pro, in which case it works as you would expect, but that doesn't solve the problem of us wanting to have it embedded as a file and be read internally, not from disk.


      So the file specification should be correct, since we can see the embedded file in the attachments and extract it correctly.  And the XObject dictionary should be set up correctly, since when the file is extracted, we can get it to render if running Pro.  It's just that for some reason, we can't get the XObject to look for the EmbeddedFile instead of an external file.


      We are using Acrobat Reader 9 for viewing and building this against the "PDF Reference, version 1.7" specifications.  This also fails when using AR8 as well.


      Options that we have tried varying are not including the EmbeddedFiles name tree entry (thus making it invisible), including or excluding the UF or DOS/Mac/Unix values on the file specification dictionary and /EF dictionary.  We've tried removing the base /F value entirely, and only had the /EF dictionary.  What else can we try to get this to work?