I agree with the configuration in general but not with the cocoon concept.
The parts like configuration, logging, etc. could help us with the 
functionality and the architecture.

To serialize between the Area Tree and the Renderers there are some 
serious problems that would get in the way:
- in many cases the area tree will need to be complete before sending 
anything across, this defeats the whole purpose and will use a lot of 
- embedded xml will need to be parsed twice and saxified
- how do we handle area tree extensions
- forward references for some renderers will mean that the renderer may 
also need to store the whole area tree (or part thereof) on the other side 
of the sax events
- the layout depends on the output target, for font information

On 2002.03.15 16:32 Nicola Ken Barozzi wrote:
> What "bugs" me in FOP currently (the famous itch to scratch ;-) , is what
> drives the whole process itself. Configuration, URI resolving, logging,
> and
> so on. The infrastructure.


> When this is in place, all the infrastructure is there, and we can
> concentrate on the real FOP code.

The problem is that the *real* FOP code significantly effects the way that 
the processing and caching works.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to