Finn Bock wrote:

> 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.initialize();
>          driver.setOutputStream(out);
>          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:
> Index:
> ===================================================================
> 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

I think I see where you are headed. I definitely do not want to proliferate
hard-coding of LayoutManagerLS (since that is now a specific layout strategy
instead of the only layout strategy, the most attention it should get is as
a default). What I did instead is commit changes that:
1. add Driver.getCurrentDocument() and Driver.setCurrentDocument() accessor
2. make the setting of the LayoutStrategy within Driver conditional on it
being null

I think you should be able to now drill down in a manner similar to the

        Driver driver = new Driver();
        Document document = new Document(driver);             //added
        driver.setCurrentDocument(document);                  //added
        LayoutManagerLS lmls = new LayoutManagerLS(document); //added
        document.setLayoutStrategy(lmls);                     //added
        lmls.setAddLMVisitor(new AddLMVisitorExtended);       //added
        driver.setRenderer(new ITextRenderer());
        driver.addElementMapping(new AcroFormElementMapping());
        driver.render(reader, new InputSource(in));

The above is uncompiled & untested. I don't have time to test it right now,
but please feel free to do so if you can -- otherwise, I'll try to get to it
in the next few days. There may very well yet be something that I have
overlooked, but I think this is the right general approach. Keep in mind
that this API will almost certainly change.

> [Victor]
> > 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.

Sorry, I was unclear here -- my comments here weren't directed toward you,
but toward the developer community at large. You have uncovered a limitation
in the Visitor pattern that I did not fully grasp when I introduced it into
the code, so I want to make sure that everyone is comfortable with the
tradeoffs that are occurring here. I am comfortable with them, and I did not
mean to imply that you were not, but rather to raise a red flag for anyone
else following this thread to comment if they have concerns.

> > 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
> > contributed),
> 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.

(Again, I didn't mean to imply that you should contribute your code).
Interesting, especially since you are using the trunk code. You are the
first person that I know of using trunk code for real work, so that is an
encouragement. Thanks for your patience in helping us work through these

Victor Mote

Reply via email to