Glen Mazza wrote: > Given that our Area tree is renderer-specific, and > since the area tree creation is tightly bound to fo > tree creation--I think any internal implementation we > would have of multiple rendering types would just > involve running FOP once for each rendering type. If > so, perhaps this is best left with Cocoon.
I saw your later posting amending the conclusion, but I want to make sure that the underlying logic is clear as well. AreaTree is not renderer-specific, but RenderContext specific. So, for example, the same AreaTree can be used to generate PostScript and PDF output. PostScript and PDF are part of the same RenderContext, whereas AWT would use a different one. (The user doesn't really have to know anything about RenderContexts because the RenderTypes can be hard-wired to them). Also, while currently it is true that the AreaTree creation is somewhat bound to the FOTree creation, that is one of the things that I think we are trying to change (I am anyway). The only reason that I know of for the processing to be the way it is now is to facilitate eager processing. If we return control of that up to these Control/API classes, we get a clean separation of these tasks, add the option for patient processing as well, and add the possibility of pluggable layout. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
