My comments earlier about the area tree and page description languages have started me thinking about the topic. The way I see it, there's no daylight between the area tree and the renderer(s). I was talking about the output from the area tree being a PDL, but Postscript and PDF are page description languages. The term renderer is misleading. Acrobat is the renderer; the PS driver, be it Ghostscript, the software in a printer or something else, is the renderer. The last stage of the FOP process translates one page description (the area tree) into another (the input to the target renderer.)
So why would anyone want to interpose another translation step into this tightly coupled arrangement? Who knows? But let's say that you do. What would you use? You could express the area tree in xml and churn that out. Maybe you want to loosely couple a renderer, using SAX events. The point is, you are passing a page description language instance across the interface. Furthermore, it's a pdl with some severe limitations, because is was designed to be tightly coupled with an fo tree processor and a layout engine. If you want a pdl to pass across the interface, why not pick one that is well understood, widely supported, and that does an excellent job of describing pages. E.g., Postscript. It's text, like xml. Unlike xml it has elaborate pre-defined semantics, so there are only certain targets that it makes any sense to direct it to; printers for example. You get my drift, I'm sure. To me, it seems a waste of time to translate the internal representation of the area tree into an external representation which is then used to reconstruct something like the area tree as input to a pdl generator. Note the sleight-of-hand in "something like". The area tree does have to be flattened into a linear series of drawing instructions, and if there were any place for externalising the area tree, it would be the output of this flattened structure. I would see that flattened structure expressed in an API, however, and would take advantage of it to construct a stream destined to cross that particular API boundary into a snap-on pdl generator. Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
