Fop
  1. Fop
  2. FOP-1498

[PATCH] PDF Embedded files implementation

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: pdf
    • Labels:
    • Environment:
      Operating System: All
      Platform: All
    • External issue ID:
      44460

      Description

      Patch to this pseudo bug will allow you to use PDF embedded files feature.

      1. patchEmbeddedFiles.txt
        37 kB
        Andrejus Chaliapinas

        Activity

        Hide
        Andrejus Chaliapinas added a comment -

        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.

        Show
        Andrejus Chaliapinas added a comment - 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.
        Hide
        Andrejus Chaliapinas added a comment -

        Attachment patchEmbeddedFiles.txt has been added with description: Patch with implementation for embedded files

        Show
        Andrejus Chaliapinas added a comment - Attachment patchEmbeddedFiles.txt has been added with description: Patch with implementation for embedded files
        Hide
        Jeremias Maerki added a comment -

        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.

        Show
        Jeremias Maerki added a comment - 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.
        Hide
        Andrejus Chaliapinas added a comment -

        (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.

        Show
        Andrejus Chaliapinas added a comment - (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.
        Hide
        Jeremias Maerki added a comment -

        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/>

        Show
        Jeremias Maerki added a comment - 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/>
        Hide
        Mark Thomas added a comment -

        Reset assignee so mails go to list.

        Show
        Mark Thomas added a comment - Reset assignee so mails go to list.
        Hide
        Jeremias Maerki added a comment -

        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

        Show
        Jeremias Maerki added a comment - 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
        Hide
        Glenn Adams added a comment -

        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

        Show
        Glenn Adams added a comment - 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

          People

          • Assignee:
            fop-dev
            Reporter:
            Andrejus Chaliapinas
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development