Patch to this pseudo bug will allow you to use PDF embedded files feature.
Created attachment 21573 [details] Patch with implementation for embedded files This is initial implementation of PDF Embedded files. It's based on "PDF Reference, fifth edition Adobe Portable Document Format version 1.6" document. This implementation will add new PDF extension to be understandable by FOP processor in such form: <pdf:embedded-file name="file name" desc="file description" src="file URI"/> In resulting PDF at this moment embedded file will stay with correct name, description, but with size shown as "Unknown". That will be enhanced probably later either with additional optional "size" attribute or by other means.
Thanks for the patch, Andrejus. I think this is a useful feature. However, looking through the patch I have the following feedback: - There's no documentation for the website. This should be documented in src\documentation\content\xdocs\trunk\output.xml to be useful for everyone. - PDFEmbeddedFileXObject should be PDFEmbeddedFile. Embedded files are no XObjects, just normal streams, so extend from AbstractPDFStream, not PDFXObject. - The dependencies inside the pdf Package to apps.FOUserAgent and into the render.pdf package are unacceptable. The PDF package will soon move to XML Graphics Commons where access to FOUserAgent and the PDF Renderer is impossible. Please use something else to transport the information. For example, you could use a JAXP StreamSource object which can contain an InputStream plus the original URI. - Please don't use tab characters and try to match the existing coding style. That keeps out own effort down when processing the patch. See also: http://xmlgraphics.apache.org/fop/dev/conventions.html I'll leave this issue assigned to you. Please revisit your patch based on the above feedback. If anything's unclear, please don't hesitate to ask.
(In reply to comment #2) > Thanks for the patch, Andrejus. I think this is a useful feature. However, > looking through the patch I have the following feedback: > - There's no documentation for the website. This should be documented in > src\documentation\content\xdocs\trunk\output.xml to be useful for everyone. Agree, will need to prepare it later. > - PDFEmbeddedFileXObject should be PDFEmbeddedFile. Embedded files are no > XObjects, just normal streams, so extend from AbstractPDFStream, not PDFXObject. Made that change locally already. > - The dependencies inside the pdf Package to apps.FOUserAgent and into the > render.pdf package are unacceptable. The PDF package will soon move to XML > Graphics Commons where access to FOUserAgent and the PDF Renderer is impossible. > Please use something else to transport the information. For example, you could > use a JAXP StreamSource object which can contain an InputStream plus the > original URI. One question here in regards to present render.pdf package dependency. If my PDF Renderer extesion uses some Value Object and I'd like to reuse members of that object during PDF objects Dictionary population - should I move then such Value Object to any other package? Or duplicate it in pdf package? In regards to apps.FOUserAgent package dependency - will rethink that place. Thank you for pointing me to the right directions.
Only just now noticed that if you assign an issue to yourself, fop-dev doesn't get notified if anything's added. Fixed now. (In reply to comment #3) <snip/> > One question here in regards to present render.pdf package dependency. If my > PDF Renderer extesion uses some Value Object and I'd like to reuse members of > that object during PDF objects Dictionary population - should I move then such > Value Object to any other package? Or duplicate it in pdf package? The value object is FOP-specific and is in the right place. But the PDF library shall remain a part that can be used independently of FOP. When you work with it, just imagine you're working with PDFBox or iText from where you don't have access to FOP classes. The PDF classes basically expose an object model for PDF. Your code (in the render.pdf package) should set the right values on this object model. That may mean that you have to expose some value once on the value object (for FOP) and once in the PDF library. So I wouldn't duplicate the value object, just provide concrete getters/setter on the dictionary subclasses. I hope you understand what I mean. <snip/>
Reset assignee so mails go to list.
I've taken Andrejus' patch and addressed my concerns on the original patch. I also extended the functionality somewhat and added documentation. Thanks for your initial work, Andrejus. It was definitely useful as a starting point. Please note that I've changed the "desc" attribute to "description" and "name" to "filename". SVN revision: http://svn.apache.org/viewvc?rev=981875&view=rev
batch transition to closed; if someone wishes to restore one of these to resolved in order to perform a verification step, then feel free to do so