Bug 44460 - [PATCH] PDF Embedded files implementation
Summary: [PATCH] PDF Embedded files implementation
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: pdf (show other bugs)
Version: trunk
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2008-02-21 01:53 UTC by Andrejus Chaliapinas
Modified: 2012-04-01 06:16 UTC (History)
1 user (show)



Attachments
Patch with implementation for embedded files (36.85 KB, patch)
2008-02-21 02:02 UTC, Andrejus Chaliapinas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrejus Chaliapinas 2008-02-21 01:53:58 UTC
Patch to this pseudo bug will allow you to use PDF embedded files feature.
Comment 1 Andrejus Chaliapinas 2008-02-21 02:02:42 UTC
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.
Comment 2 Jeremias Maerki 2008-02-21 02:43:43 UTC
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.
Comment 3 Andrejus Chaliapinas 2008-02-21 09:11:47 UTC
(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.
Comment 4 Jeremias Maerki 2008-02-26 09:15:44 UTC
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/>
Comment 5 Mark Thomas 2009-06-10 13:23:18 UTC
Reset assignee so mails go to list.
Comment 6 Jeremias Maerki 2010-08-03 09:51:30 UTC
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
Comment 7 Glenn Adams 2012-04-01 06:16:27 UTC
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