Fop
  1. Fop
  2. FOP-1809

[PATCH] Enhancement to the include page segment functionality for AFP rendering

    Details

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

      Description

      This patch facilitates the extraction and embedding of a page segment from a resource file into the generated AFP. The include-page-segment extension element permits the optional attribute 'resource-file' that is the URI to the resource containing the named page segment.

      1. 49379.patch
        32 kB
        Peter Hancock

        Activity

        Hide
        Jeremias Maerki added a comment -

        Patch applied with modifications as discussed:
        http://svn.apache.org/viewvc?rev=1005350&view=rev

        Thanks, Peter, and sorry for the long time it took to process your patch!

        BTW, while working on this it occurred to me that with the embedding functionality, we're actually making page segment handling overly complicated: we always need a replacement image that the layout image is actually working with. I'm not saying that this addition was a bad one, but we should think about making it easier in the future, namely by supporting AFP page segments directly through fo:external-graphic. The first step here would be native embedding support (just reading the intrinsic size of the page segment). A second step could even be decoding page segments and supporting them for other output formats. Just a thought.

        Show
        Jeremias Maerki added a comment - Patch applied with modifications as discussed: http://svn.apache.org/viewvc?rev=1005350&view=rev Thanks, Peter, and sorry for the long time it took to process your patch! BTW, while working on this it occurred to me that with the embedding functionality, we're actually making page segment handling overly complicated: we always need a replacement image that the layout image is actually working with. I'm not saying that this addition was a bad one, but we should think about making it easier in the future, namely by supporting AFP page segments directly through fo:external-graphic. The first step here would be native embedding support (just reading the intrinsic size of the page segment). A second step could even be decoding page segments and supporting them for other output formats. Just a thought.
        Hide
        Jeremias Maerki added a comment -

        Peter, I've taken a look at your patch. I found that I get an IOException when referencing the page segment "s1islogo.psg" that comes with IBM AFP Workbench:

        java.io.IOException: Malformed AFP resource with name 's1islogo': No Begin structured field
        at org.apache.fop.afp.util.AFPResourceUtil.copyNamedResource(AFPResourceUtil.java:123)

        I have the impression that the method AFPResourceUtil.findStart() may not be ideal to parse an MO:DCA file. I haven't investigated more closely why the above file fails, but stepping through findStart() feels a bit weird in terms of how that method looks for the requested resource. Some time ago I started a rudimentary AFP parser I used to dump the Type 1 data from an outline font, or to simply dump the basic structure of an AFP file. I could include that in FOP and we build from there. It allows to return an object for each structured field encountered. A generic MO:DCA parser would also allow future functionality that involves parsing an AFP file. WDYT?

        Show
        Jeremias Maerki added a comment - Peter, I've taken a look at your patch. I found that I get an IOException when referencing the page segment "s1islogo.psg" that comes with IBM AFP Workbench: java.io.IOException: Malformed AFP resource with name 's1islogo': No Begin structured field at org.apache.fop.afp.util.AFPResourceUtil.copyNamedResource(AFPResourceUtil.java:123) I have the impression that the method AFPResourceUtil.findStart() may not be ideal to parse an MO:DCA file. I haven't investigated more closely why the above file fails, but stepping through findStart() feels a bit weird in terms of how that method looks for the requested resource. Some time ago I started a rudimentary AFP parser I used to dump the Type 1 data from an outline font, or to simply dump the basic structure of an AFP file. I could include that in FOP and we build from there. It allows to return an object for each structured field encountered. A generic MO:DCA parser would also allow future functionality that involves parsing an AFP file. WDYT?
        Hide
        Peter Hancock added a comment -

        Attachment 49379.patch has been added with description: Patch

        Show
        Peter Hancock added a comment - Attachment 49379.patch has been added with description: Patch

          People

          • Assignee:
            fop-dev
            Reporter:
            Peter Hancock
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development