J.Pietschmann wrote: > Victor Mote wrote: > > If you can convince me that it is not possible for layout and > rendering to > > be refactored into distinct tasks or "services", then my interest in FOP > > diminishes to zero, and I'll stop making so much noise. I don't > see why that > > should be true. > > Layout and rendering can be factored into different packages > of services, actually this is already done to a large extent. > However, the interface is quite complex, and I don't think you > can plug in the old layout engine without rewriting significant > parts of it into the framework provided by HEAD.
Agreed. > > I don't follow your point about SVG. From a big-picture, abstract > > standpoint, why do we need to think of SVG any differently than > any other > > graphic type? > > Inlined SVG code is parsed by the FOTreeBuilder. In any case, > the FOTreeBuilder must have at least some knowledge about anything > wich can appear in instream-foreign-object. OK, now I follow. Yes, the difference between SVG & other graphics packages would be the namespace issue. The FOTree builder needs to know what to do with the namespace. So, for a renderer-agnostic FOTree builder to work properly, it should parse the SVG & create the necessary objects in the FOTree. The Renderer (this would be the workhorse object that actually renders, not the somewhat-related RenderType control object that controls) then should be responsible to either ignore it or place it into the output, depending on its capabilities. But the FOTree builder doesn't need to know or care. (At the risk of getting esoteric, if the Document object knows that none of the output options requested support SVG, it could tell the FOTree builder to ignore that namespace and save the memory. FOTree builder still doesn't need to know or care about why, it simply "serves" Document). Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
