--- "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 one.
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--
Shucks.
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 <http://www.apache.org/~andyc/neko/doc/pull/index.html>, XmlPull <http://www.xmlpull.org/>, JSR173 Streaming API for XML <http://jcp.org/en/jsr/detail?id=173>, or the WebLogic XML Streaming API <http://e-docs.bea.com/wls/docs70/xml/xml_stream.html>, 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 API.
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.
</Press>
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 -- Peter B. West <http://cv.pbw.id.au/>
