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
Created attachment 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?
(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
(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.
Change done as proposed: http://svn.apache.org/viewvc?view=rev&revision=680369
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed