--- "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--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.) 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. Glen
