FOP
  1. FOP
  2. FOP-1558

Better support for overriding default LayoutManagerMaker needed

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.94
    • Fix Version/s: None
    • Component/s: layout/unqualified
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All
    • External issue ID:
      45470

      Description

      I have the requirement to replace the default BlockContainerLayoutManagerMaker with my own implementation. After searching the code base I think the suggested way is by using the setLayoutManagerMakerOverride(LayoutManagerMaker) method of the FopFactory to override the default LayoutManagerMaker implementation.

      My own LayoutManagerMaker is a subclass of the default LayoutManagerMapping.
      Unfortunately, 'cause the map of LayoutManagerMakers is private and no protected setter is given to change the default mapping set during initialize(), one has to provide a second map of LayoutManagerMakers and duplicate a lot of code to tell fop to use this new mapping.

      My suggestion:
      Either make the map of LayoutManagerMakers protected or preferably provide a protected setter to change the default mapping.

      Thanks in advance
      Rainer

        Activity

        Hide
        Jeremias Maerki added a comment -

        Agreed, this is indeed not a good situation at the moment. I guess nobody really needed that feature. I prefer a protected setter. I'll attach a patch as proposal. If I don't hear any objections in the next 72 hours I'll commit the patch. Out of curiosity: what do you need to replace the block-container LM for?

        Show
        Jeremias Maerki added a comment - Agreed, this is indeed not a good situation at the moment. I guess nobody really needed that feature. I prefer a protected setter. I'll attach a patch as proposal. If I don't hear any objections in the next 72 hours I'll commit the patch. Out of curiosity: what do you need to replace the block-container LM for?
        Hide
        Jeremias Maerki added a comment -

        Attachment LayoutManagerMapping-proposal.diff has been added with description: Proposed patch for the improvement

        Show
        Jeremias Maerki added a comment - Attachment LayoutManagerMapping-proposal.diff has been added with description: Proposed patch for the improvement
        Hide
        Rainer Langbehn added a comment -

        (In reply to comment #1)
        > Created an attachment (id=22308) [details]
        > Proposed patch for the improvement
        >
        > Agreed, this is indeed not a good situation at the moment. I guess nobody
        > really needed that feature. I prefer a protected setter. I'll attach a patch as
        > proposal. If I don't hear any objections in the next 72 hours I'll commit the
        > patch. Out of curiosity: what do you need to replace the block-container LM
        > for?
        >

        Jeremias,
        ...you're really fast Thanks for the patch.

        FYI, I'm working on a collection of XSL Transformation stylesheets (XSLT) to convert documents/forms from Adobe's XML Data Package (XDP) vocabulary into documents in the W3C's XSL Formatting Objects (XSL-FO) vocabulary (eventually with embedded XForms), http://xdp2fo.sourceforge.net. This project is still
        in an early phase but the already produced outputs are very promising.

        Some of the XDP container elements, which I map to absolute positioned block containers, use the concept of an anchor point for positioned layout. The location of the container's anchor point can be: topLeft, topCenter, topRight, middleLeft, middleCenter, middleRight, bottomLeft, bottomCenter, bottomRight.
        The given top and left coordinates are always related to the anchor point. In
        my opinion there is no corresponding concept in XSL-FO. Therefore you have to transform the left and top coordinates (writing mode is currently not respected) in accordance to the anchor type given.

        After some research my choosen solution looks like this:

        1. During transformation embed the XDP anchorType attribute in the
        corresponding block-container element (with XDP namespace).
        2. Provide an extended BlockContainerLayoutManager that looks for this special
        attribute during layout processing. If such an attribute is found, perform
        the position adjustment after bpd and ipd are computed.
        3. Remove the XDP attribute after processing.

        What do you think about this solution? Do you know a better or simpler solution? The drawback of my solution is, you have to provide this extension
        for every possible XSL-FO processor.

        BTW, for barcode processing I'm using Barcode4J. Thanks for all your great work.

        Bye Rainer

        Show
        Rainer Langbehn added a comment - (In reply to comment #1) > Created an attachment (id=22308) [details] > Proposed patch for the improvement > > Agreed, this is indeed not a good situation at the moment. I guess nobody > really needed that feature. I prefer a protected setter. I'll attach a patch as > proposal. If I don't hear any objections in the next 72 hours I'll commit the > patch. Out of curiosity: what do you need to replace the block-container LM > for? > Jeremias, ...you're really fast Thanks for the patch. FYI, I'm working on a collection of XSL Transformation stylesheets (XSLT) to convert documents/forms from Adobe's XML Data Package (XDP) vocabulary into documents in the W3C's XSL Formatting Objects (XSL-FO) vocabulary (eventually with embedded XForms), http://xdp2fo.sourceforge.net . This project is still in an early phase but the already produced outputs are very promising. Some of the XDP container elements, which I map to absolute positioned block containers, use the concept of an anchor point for positioned layout. The location of the container's anchor point can be: topLeft, topCenter, topRight, middleLeft, middleCenter, middleRight, bottomLeft, bottomCenter, bottomRight. The given top and left coordinates are always related to the anchor point. In my opinion there is no corresponding concept in XSL-FO. Therefore you have to transform the left and top coordinates (writing mode is currently not respected) in accordance to the anchor type given. After some research my choosen solution looks like this: 1. During transformation embed the XDP anchorType attribute in the corresponding block-container element (with XDP namespace). 2. Provide an extended BlockContainerLayoutManager that looks for this special attribute during layout processing. If such an attribute is found, perform the position adjustment after bpd and ipd are computed. 3. Remove the XDP attribute after processing. What do you think about this solution? Do you know a better or simpler solution? The drawback of my solution is, you have to provide this extension for every possible XSL-FO processor. BTW, for barcode processing I'm using Barcode4J. Thanks for all your great work. Bye Rainer
        Hide
        Jeremias Maerki added a comment -

        (In reply to comment #2)
        > What do you think about this solution? Do you know a better or simpler
        > solution? The drawback of my solution is, you have to provide this extension
        > for every possible XSL-FO processor.

        Sorry, but I don't have a qualified opinion here as I know nothing of this XDP. But it definitely sounds suboptimal if you have to hack a FO processor to make this work.

        Show
        Jeremias Maerki added a comment - (In reply to comment #2) > What do you think about this solution? Do you know a better or simpler > solution? The drawback of my solution is, you have to provide this extension > for every possible XSL-FO processor. Sorry, but I don't have a qualified opinion here as I know nothing of this XDP. But it definitely sounds suboptimal if you have to hack a FO processor to make this work.
        Hide
        Jeremias Maerki added a comment -
        Show
        Jeremias Maerki added a comment - Change done as proposed: http://svn.apache.org/viewvc?view=rev&revision=680369
        Hide
        Glenn Adams added a comment -

        batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development