Keiron Liddle wrote: > On 2002.03.14 09:00 Nicola Ken Barozzi wrote: > >> What I would like to see, is that FOP stops discussing about the >> logging, >> resolving, pipelineing and stuff and starts to focus on the core >> functionality. >> IMHO, the best way to get this thing going *quick* is to use Cocoon as a >> pipeline. Cocoon gives you all these features, and gives you a solid >> framework to work on. >> When it works on Cocoon, we can see if performance for stand-alone >> processing is good enough. If not, we can *then* talk about the >> structure >> around FOP, and break eventually free from Cocoon. > > > Firstly the Area Tree is unavoidable.
Hear, hear. > We must have a place to do the layout and to store the page information. > If you want this area tree turned into sax events, it really seems > like an unecessary step but there is an xml renderer (admittedly > simply writes text at the moment but you get the idea) if you want to > add this extra step. Agree strongly. At various times the notion of "flattening the area tree" has been wrestled with in these pages. At some point the tree model of pages loses all relevance. Trees are very useful to describe the structure of the "stuff" being squirted onto the page. At the end of the day, though, the "stuff" is rendered as a series of marks on a flat surface, and, to the renderer of last resort, all of the data structures that generated the marks are irrelevant. I am utterly ignorant of any particular page description languages, so imagine such a language that provides for the drawing of certain sorts of marks on the page at certain co-ordinates. That, essentially, is the output of the area tree. If you want to express that page definition language in xml, go right ahead. Xml output would indeed be loosely coupled. It's a data stream. SAX events are about as loosely coupled as tree roots. It's an API, after all, and an API which is inimical to pipelining processes. However, if you want to be able to feed the area tree into various renderers, you have to use some sort of PDL to transcribe the area tree, and the description is linear set of random access instructions, whether expressed in an xml file or an API. > > The FO Tree - Layout - Area Tree are the three core issues. This is > what needs to be done first. Yes. > > For the FOTree to structure document it is a different issue, that I > hope we will solve one day. Maybe sax events could be used here. > My own approach is an API-based pipeline. As you say, these three, FO Tree - Layout (Tree?) - Area Tree, are the tightly coupled core issues. Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
