You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2008/07/23 21:38:55 UTC
DO NOT REPLY [Bug 45470] New: Better support for overriding default
LayoutManagerMaker needed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45470
Summary: Better support for overriding default LayoutManagerMaker
needed
Product: Fop
Version: 0.94
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: page-master/layout
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: langbehn@netcologne.de
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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45470] Better support for overriding default
LayoutManagerMaker needed
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45470
Glenn Adams <gl...@skynav.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #5 from Glenn Adams <gl...@skynav.com> 2012-04-01 07:01:50 UTC ---
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45470] Better support for overriding default
LayoutManagerMaker needed
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45470
--- Comment #1 from Jeremias Maerki <je...@apache.org> 2008-07-23 12:53:37 PST ---
Created an attachment (id=22308)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22308)
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?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45470] Better support for overriding default
LayoutManagerMaker needed
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45470
--- Comment #3 from Jeremias Maerki <je...@apache.org> 2008-07-23 23:33:31 PST ---
(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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45470] Better support for overriding default
LayoutManagerMaker needed
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45470
Rainer Langbehn <la...@netcologne.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45470] Better support for overriding default
LayoutManagerMaker needed
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45470
--- Comment #2 from Rainer Langbehn <la...@netcologne.de> 2008-07-23 13:47:14 PST ---
(In reply to comment #1)
> Created an attachment (id=22308)
--> (https://issues.apache.org/bugzilla/attachment.cgi?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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45470] Better support for overriding default
LayoutManagerMaker needed
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45470
Jeremias Maerki <je...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Jeremias Maerki <je...@apache.org> 2008-07-28 07:27:38 PST ---
Change done as proposed: http://svn.apache.org/viewvc?view=rev&revision=680369
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.