On 11.01.2003 18:35:37 Victor Mote wrote:
> 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?

The performance gain is not having to do the layout for each output
document which is the major part of a processing run.

The system I wrote for my former employer which is a solution for
high-volume digital printing had to provide a minimal number of pages
per minute. That's usually about 1 to 2 times the speed of the target
printer. So if you have a Xerox DocuTech with 180 pages per minute
and you have to fill an archive with a different format than the one
sent to the printer you'll be happy for such a feature. Especially, if
legal requirements dictate that you need to be able to reprint the
document from the archive and get the same document almost to the pixel.

I'd say we need to be able to do this sometime in the future but not
necessarily now. So let's just make sure this requirement doesn't get
lost and that it stays in the back of our minds when we design the new

> 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.

That's bad, yes.

Or you could only allow one RenderingContext which results in a
restriction of the available fonts based on the output handlers. You'd
get an error message as soon as an unsupported font is used. When a
common set isn't possible you have to do two rendering runs anyway so we
might just as well delegate this to the caller/user.

> 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?

Won't be necessary with my alternative apporach above. But if the user
has to run the layout twice it might be good if the FO tree wasn't lost
between runs.

> 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.

I think my approach could work in this regard. I'm not sure. We can let
the FO tree live for another layout run, can't we?

Jeremias Maerki

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

Reply via email to