Glen Mazza wrote:
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:

Jeremias' ideas about factoring out useful
stand-alone elements from the combination of FOP and Batik are essential to the
direction I am taking with layout and rendering, aside from being a Good
Thing in their own right.

Yes, I've pulled about 8 methods from the Renderer
interface so far, giving Renderer implementors a
little more freedom in how they choose to implement

Also, I removed direct
FOTreeBuilder.addElementMapping() methods which should
HEAD a little bit more FAD-friendly (FAD, of course,
doesn't have element mappings).  The external user
sets them in FOUserAgent instead, and HEAD's
FOTreeBuilder reads from the FOUserAgent object to
obtain them.  The FAD version of an FOTreeBuilder
would simply ignore this setting.

This doesn't mean I'm trying to move to FAD's pull
parsing--I'm not--


but if I can increase the number of
components you can use, so much the better.  (To that
end, notice the one-line of code in
getDefaultHandler() in Driver that initializes
FOTreeBuilder.  If FAD's FOTreeBuilder equivalent can
work with these arguments--a render type, output
stream, FOUserAgent object--great!  That would mean
fop.apps package can be the same between two systems.)

I think there are some possibilities here. A lot of what you are doing seems kindred (in spirit, at least) with Victor's approach. I'll take whatever I can get from FOP for FAD, and the more commonality the better. But there is a fundamental difference in approach to XML events in pull parsing, which liberates application processing to a degree which I don't think is appreciated by habituated SAX users. In FAD the scope of XML parsing is entirely circumscribed by the parser thread, which runs on-demand.

All of the requirements for inputs, transformations, etc, are the same, because I am using SAX "under the hood." But when a native pull parser comes along, say as a result of Andy Clark's work with NekoPull <>, XmlPull <>, JSR173 Streaming API for XML <>, or the WebLogic XML Streaming API <>, I will happily ditch SAX. Whether the Streaming API will be JAXP compliant is a moot point. If not, it is another wedge between FOP and FAD.

In general, I'm trying to move away from supporting
direct manipulation of internal objects from external
users: e.g., AreaTree.setWidget(), etc. and instead am
placing the customization in FOUserAgent (or the xml
configuration file, perhaps) for the internal objects
to read.  That way if an alternative implementation
has nothing to do with widgets, it can simply ignore
the setting in FOUserAgent without being forced to
implement an architecture-breaking setWidget().  This
also gives future implementors ability to completely
revamp things internally without worrying about the

The layout engine that I'm currently working on looks as though it will have three threads - a parser thread (which will disappear in a streaming parser), a layout engine and a renderer.

<Press button="Repeat">
The Area tree is built in lockstep with the FO tree. An area may provide the context for the resolution of properties on the descendants of the FO that generated that area. The integration is that tight. Furthermore, page layout begins with the start tag of a page-sequence fo:flow, not the end-tag. It is pull parsing that makes this feasible, and makes possible the solution of FOP's most critical problem - memory. It doesn't matter how long the page sequence is in FAD.

An API which is to accommodate both FOP and FAD must be able to span such fundamental differences.

Incidentally, IIUC, the above is not to do with "eager" layout. That was a property of layout strategies, concerning how much *layout* context was examined before a final layout decision was taken. In my understanding, it related to the ability to adjust layout across multiple paragraphs or pages in order to find a better quality solution, as opposed to making those decisions based only on local layout information. The same decisions must be made in FAD.

However, the first order of business for FAD is to get basic layout working, then demonstrate multi-columns with footnotes, marker processing with inheritance from static-content, floats, keeps, and last-page processing, in no particular order.

Peter B. West <>

Reply via email to