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]

Reply via email to