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 

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.


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

Reply via email to