Re: Large files.
The problem with Keirons layout code (with respect to large input
files) is that it works top-down on the LM tree and thus require the
creating of the complete LM tree for the page sequence. To better fit
within SAX event model the layout process should also be event driven,
triggered f.ex by the endBlock() and character() events. That means
that the traversing of the FOTree cannot be easily done using
recursive decend. Instead the main loop over the FO tree could use a
non-recusive tree treverse like this:
public Element traverse(Node q, Node end, int mode) {
while (q != end) {
switch (mode) {
case FIRST:
// First time in the node.
preorder(q);
if (q.hasChildNodes()) {
q = q.getFirstChild();
break;
}
mode = NEXT;
// fallthrough
case NEXT:
// All children are handled.
postorder(q);
// Add the node to its parent.
if (q.getParentNode() != null) {
child(q.getParentNode(), q);
}
// fallthrough
case RESTART:
// Attempt to move vertically to next sibling.
horizontally?
if (q.getNextSibling() != null) {
q = q.getNextSibling();
mode = FIRST;
break;
}
// No sibling found, move to the parent to
// do postorder.
q = q.getParentNode();
mode = NEXT;
}
}
return null;
}
...
The loop can be stopped when we temporary run out of FO tree nodes and
restarted again when new nodes has been added. I suppose that the FO
tree can then be viewed as a stream of FO nodes.
[Peter]
I suppose so. And I suppose that making layout event-driven would
better fit in with the SAX event model. It just doesn't make sense from
the point of view of layout which is basically a top-down process.
By top-down, do you mean the visiting order of the nodes in the tree? Or
the structure of the code that does the layout? Like this:
process(Node n) {
preorder(n)
for (each child in n) {
process(child)
child(n, child);
}
postorder(n);
}
The traverse() code does the exact same as the process() code. The
differences are:
- All people immediately recoqnize process().
- process() can use local variables to store state.
A major drawback of process() is that is darn hard to suspend processing
and then restart it. Our current getNextBreakPoss() code is a nice
example of just how hard it is.
regards,
finn
Re: Large files.
Finn Bock wrote:
The loop can be stopped when we temporary run out of FO tree nodes
and restarted again when new nodes has been added. I suppose that the
FO tree can then be viewed as a stream of FO nodes.
[Peter]
I suppose so. And I suppose that making layout event-driven would
better fit in with the SAX event model. It just doesn't make sense
from the point of view of layout which is basically a top-down process.
By top-down, do you mean the visiting order of the nodes in the tree? Or
the structure of the code that does the layout? Like this:
process(Node n) {
preorder(n)
for (each child in n) {
process(child)
child(n, child);
}
postorder(n);
}
The traverse() code does the exact same as the process() code.
I noticed that, and wondered what you were getting at.
The
differences are:
- All people immediately recoqnize process().
- process() can use local variables to store state.
A major drawback of process() is that is darn hard to suspend processing
and then restart it. Our current getNextBreakPoss() code is a nice
example of just how hard it is.
The penny drops. There has always been a requirement for some form of
co-routine, and I see now what you are getting at. I think I see why
you mentioned this in the same breath as the SAX event model, but that
confuses the issue, I think. What you are proposing is compatible with
stream parsing, and in fact, fits quite well. Alt-design parsing
provides on-demand events to the FO tree builder, and is automatically
regulated by up-stream demand.
It seems to me that the events most natural to the layout process are
events in the FO tree, and that the main requirement for restarts in
the FO tree is to do with the inherent dialogue between FO and Area
trees. However, the discussion is too general, and my understanding of
the particular problems you are addressing is too vague, for me to make
meaningful comments.
Peter
[GUMP@brutus]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 14 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 31 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-10122004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-10122004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-10122004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-10122004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-10122004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-10122004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - junit: [javac] Compiling 31 source files to /home/gump/workspaces2/public/workspace/xml-fop/build/test-classes [javac] This version of java does not support the classic compiler; upgrading to modern [javac] /home/gump/workspaces2/public/workspace/xml-fop/test/java/org/apache/fop/util/ASCII85InputStreamTestCase.java:25: warning:
Re: Large files.
Victor Mote wrote: Finn Bock wrote: The loop can be stopped when we temporary run out of FO tree nodes and restarted again when new nodes has been added. I suppose that the FO tree can then be viewed as a stream of FO nodes. This model probably works fine if you never need to look ahead, but there are numerous examples (well discussed in the archives) where one does need to do that, the most obvious being automatic table layout. Peter's solution to that is pull parsing, which probably works, but forces an intermingling of interests that I need to avoid. My solution is to serialize the FOTree as necessary (I do not have this working). The bottom line is that, if you conceivably need to see both the beginning and end of the input simultaneously (which we do), and you are writing so that disk space is the only constraining factor, you will have to either be prepared to re-parse the data (Peter's approach) or to serialize what has already been parsed (my approach). Victor, I think you may have misinterpreted an aspect of Defoe's design. The re-parsing (of attribute data) is only required for static-content and markers. Even then, it is not essential, merely the simplest way to achieve the result, given a stream of pre-parsed (in SAX terms) events. I'm quite happy with serializing the partial results where rendering cannot be resolved due to forward references. I don't see auto table layout and other localized look-ahead requiring this. I have never been able to see a third alternative. But I am always open to new ideas. I rather suspect that the current FOP design is oriented toward common use-cases rather than a comprehensive treatment that will handle all cases. Peter
RE: Large files.
Peter B. West wrote: Victor, I think you may have misinterpreted an aspect of Defoe's design. The re-parsing (of attribute data) is only required for static-content and markers. Even then, it is not essential, merely the simplest way to achieve the result, given a stream of pre-parsed (in SAX terms) events. I'm quite happy with serializing the partial results where rendering cannot be resolved due to forward references. I don't see auto table layout and other localized look-ahead requiring this. Now that you mention it, I recall you saying something about a temporary data structure (IIRC), to which I replied sounds like an FO Tree, to which I never received a substantive reply. My apologies -- I didn't mean to misrepresent Defoe. I have some other comments on the table layout and look-ahead issues, but I'll make them to you off-line, because I think the FOP folks don't want the design conversations here. My apologies for my part in starting this thread. Simon's original comment could be interpreted in either a general or specific way, and I just wanted to clarify that aspect of it. I didn't mean to start a debate at all. Victor Mote
Re: Large files.
Finn Bock wrote:
...
The problem with Keirons layout code (with respect to large input files)
is that it works top-down on the LM tree and thus require the creating
of the complete LM tree for the page sequence. To better fit within SAX
event model the layout process should also be event driven, triggered
f.ex by the endBlock() and character() events. That means that the
traversing of the FOTree cannot be easily done using recursive decend.
Instead the main loop over the FO tree could use a non-recusive tree
treverse like this:
public Element traverse(Node q, Node end, int mode) {
while (q != end) {
switch (mode) {
case FIRST:
// First time in the node.
preorder(q);
if (q.hasChildNodes()) {
q = q.getFirstChild();
break;
}
mode = NEXT;
// fallthrough
case NEXT:
// All children are handled.
postorder(q);
// Add the node to its parent.
if (q.getParentNode() != null) {
child(q.getParentNode(), q);
}
// fallthrough
case RESTART:
// Attempt to move vertically to next sibling.
horizontally?
if (q.getNextSibling() != null) {
q = q.getNextSibling();
mode = FIRST;
break;
}
// No sibling found, move to the parent to
// do postorder.
q = q.getParentNode();
mode = NEXT;
}
}
return null;
}
...
The loop can be stopped when we temporary run out of FO tree nodes and
restarted again when new nodes has been added. I suppose that the FO
tree can then be viewed as a stream of FO nodes.
I suppose so. And I suppose that making layout event-driven would
better fit in with the SAX event model. It just doesn't make sense from
the point of view of layout which is basically a top-down process.
BTW, datatypes.Node has getPrecedingSibling(), getFollowingSibling() and
many other doodads. First code I ever wrote for FOP.
Peter
