--- Comment #2 from Rainer Langbehn <[EMAIL PROTECTED]> 2008-07-23 13:47:14
(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
> 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
...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
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.