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: Driver.java
> ===================================================================
> RCS file:
> /home/cvspublic/xml-fop/src/java/org/apache/fop/apps/Driver.java,v
> retrieving revision 1.39
> diff -u -r1.39 Driver.java
> --- Driver.java 10 Sep 2003 06:25:36 -0000 1.39
> +++ Driver.java 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
methods
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
following:
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.initialize();
driver.setOutputStream(out);
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.
>
> http://www.lowagie.com/iText/
>
> 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
issues.
Victor Mote
