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