You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2001/11/01 03:46:11 UTC

[REDESIGN] Serializing activities

I have been thinking about the way to make processing sequence more
manifest in the code design.  It seems to me that the steps

parse the input
build the FO tree
build the Area tree
render the Area tree

need to be made more transparent, along the lines of the serialization
of the parsing that I have experimented with in XMLEventSource.java.

The problem is that all of these activities are overlapped in any design
that tries, reasonably, to minimise the memory requirements and the time
to initial output.  Parsing activities, e.g., are synchronous, so the 
parsing phase will be active until the EndDocument event is recognized. 
  In an overlapped system, all of the above phases will be active in 
parallel.  This, I think, makes for inherent difficulties in 
understanding, which sends ripples, or shock waves, through the design 
and maintenance of the code.  The OO paradigm tends to exacerbate this 
problem.

With XMLEventSource, I tried to do what I believe the SAX parser should 
do anyway - provide a single output stream.  That output stream is fed 
through a classic synchronized producer-consumer FIFO.  The processes 
still proceed inparallel, but the phases are completely disentangled. 
the same thing can be done with the other phases.

    PARSE
      |
      v
  xmlEvents
      |
      v
  FO Input Q
      |
      v
    FO Tree <----- FO
    Builder     Request Q
       |            ^
       v            |
   foEvents         |
       |        FO archive
       v         requests
Area Input Q       ^
       |            |
       v            |
   Area Tree ---->--+
    Builder  <--- Area
       |        Request Q
       v            ^
   areaEvents       |
       |            |
       v       Area archive
    Renderer     requests
    Input Q         ^
       |            |
       v            |
    Renderer --->---+


It fits with what seems almost the necessary layout processing structure 
of flow sets feeding layout element queues.

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org