Keiron Liddle wrote:
> If I understand it correctly we could have:
> - multiple output targets for one rendering run
> - targets with the same font metrics can layout to a common area tree
> - targets with similar or substitute metrics could force layout
> to one area tree
> - other targets can have different area trees from the same fo tree
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
2. If we have a RenderingContext concept, doesn't that mean that we need to
know what that RenderingContext is for each output target before we start
processing? To do any good, we must sort like RenderingContexts & process
them together. Since we don't complete parsing of the document until the
very end, it seems like we would have to parse the complete document before
knowing what the Context looks like.
3. If we were to switch to a model that completely parses the document at
the beginning (looking for RenderingContext differences), then we might want
to build the FO tree at the same time?
4. If we build the FO tree up front & let it persist, then you can achieve
the same thing in series instead of in parallel. (All of this comes at the
price of greater memory consumption, or else caching). For example:
parse doc, build FO tree, build RenderingContexts
for each RenderingContext {
build an area tree
for each output medium in this RenderingContext {
render
}
delete area tree
}
Even in this serial design, you could multi-thread either or both of the two
loops.
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
