Victor Mote wrote:

The LayoutManagerLS object is instantiated at line 584 of apps.Driver. I
guess I don't know enough about your workflow to give you a good answer
here. I thought from a previous post that you were modifying apps.Driver.

Until now, is hasn't been necessary for me to modify Driver. I have used the Driver class like this.

        Driver driver = new Driver();
        driver.setRenderer(new ITextRenderer());
        driver.addElementMapping(new AcroFormElementMapping());
        driver.render(reader, new InputSource(in));

It would be very helpful if the Driver class had a way
of configuring the LS, for example:

RCS file: /home/cvspublic/xml-fop/src/java/org/apache/fop/apps/,v
retrieving revision 1.39
diff -u -r1.39
--- 10 Sep 2003 06:25:36 -0000      1.39
+++ 16 Sep 2003 06:37:21 -0000
@@ -581,7 +581,7 @@
         /** LayoutStrategy is hard-wired for now, but needs to be made
         accessible through the API and/or configuration */
         if (foInputHandler instanceof FOTreeHandler) {
-            currentDocument.setLayoutStrategy(new LayoutManagerLS(currentDocument));
+            currentDocument.setLayoutStrategy(getLayoutManagerLS(currentDocument));
         treeBuilder.foTreeControl = currentDocument;
         try {
@@ -633,6 +633,11 @@
             throw new FOPException(e);
+    protected LayoutManagerLS getLayoutManagerLS(Document currentDocument) {
+        return new LayoutManagerLS(currentDocument);
+    }

      * This method overloads the main render() method, adding the convenience

You're right that [...] the cast is necessary. I
just committed a change to mitigate this:
1. converts FOTreeVisitor to an interface, which will allow you to extend
the interface & implement the extended interface in your extension of
AddLMVisitor. This way you can cast the visitor as an FOTreeVisitorExtension
instead of an AddLMVisitorExtension, which (to my mind anyway) keeps the
layout stuff out of the FO Tree logic. So conceptually, you are doing two
things: a) adding a new element into the FO Tree (extending the
FOTreeVisitor), b) doing something with that new element in layout
(extending AddLMVisitor).
2. converts the methods to unique names instead of overloading one method
name. I don't think this directly affects the issue at hand, other than
perhaps making the method selection a bit less obtuse.

This looks very good.


I was think of the situation where two independently developed
extensions both need to add their own serveXXX methods to the
AddLMVisitor instance. Since there is only one AddMVisitor instance, my
extension will exclude the use of all other 3rd party extensions. But
this is not yet an actual issue for me.


OK, I see your point. Some possible workarounds:
[workarounds snipped]
This kind of opens the question of how much FOP's design should be
influenced by such issues, and I don't have a good answer.

I was merely pointing out a possible limitation.

Since it is open
source, the possibility exists of getting the extension built into the
standard code. If it is proprietary code (and therefore can't be

As such, it is not proprietary, but I doubt that it can be contributed. The extension adds acroform fields (text, checkbox, signature, etc) to PDF files, but I decided to to use iText for the generation of the PDF. This way I could used the support for acroform fields that already existed in iText and I only had to rewrite the PDFRenderer from fop into using the iText API instead of the org.apache.fop.pdf API.

Apart from the unimplemented features in fop layouting, I'm quite happy
with the result.

then I have to question how badly we should contort FOP to
make it easy to do that. There certainly seems to be a finite limit to how
much can be done at a practical level.

I agree completely with both statements. What fop has now in extension support is enough to make me do what I need.


Reply via email to