cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
vmote 2003/08/15 23:43:51
Modified:src/java/org/apache/fop/apps Driver.java
src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
FObjMixed.java PropertyManager.java XMLObj.java
src/java/org/apache/fop/fo/flow InstreamForeignObject.java
src/java/org/apache/fop/fo/pagination Root.java
Log:
1. tie Document to fo.FOTreeBuilder and fo.pagination.Root
2. add getDocument() method to FONode (using this.parent for all nodes except Root)
3. start using getDocument() to gain access to font collections stored in Document
Revision ChangesPath
1.26 +1 -0 xml-fop/src/java/org/apache/fop/apps/Driver.java
Index: Driver.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/Driver.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Driver.java 15 Aug 2003 20:37:51 - 1.25
+++ Driver.java 16 Aug 2003 06:43:50 - 1.26
@@ -601,6 +601,7 @@
if (foInputHandler instanceof FOTreeHandler) {
currentDocument.setLayoutStrategy(new LayoutManagerLS());
}
+treeBuilder.document = currentDocument;
try {
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
1.6 +6 -0 xml-fop/src/java/org/apache/fop/fo/FONode.java
Index: FONode.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FONode.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FONode.java 29 Jul 2003 18:42:31 - 1.5
+++ FONode.java 16 Aug 2003 06:43:51 - 1.6
@@ -61,6 +61,7 @@
// FOP
import org.apache.fop.apps.FOPException;
+import org.apache.fop.control.Document;
import org.apache.fop.util.CharUtilities;
/**
@@ -209,5 +210,10 @@
protected boolean isMarker() {
return false;
}
+
+public Document getDocument() {
+return parent.getDocument();
+}
+
}
1.10 +7 -2 xml-fop/src/java/org/apache/fop/fo/FOTreeBuilder.java
Index: FOTreeBuilder.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOTreeBuilder.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- FOTreeBuilder.java29 Jul 2003 19:33:29 - 1.9
+++ FOTreeBuilder.java16 Aug 2003 06:43:51 - 1.10
@@ -54,6 +54,8 @@
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
+import org.apache.fop.control.Document;
+import org.apache.fop.fo.pagination.Root;
// SAX
import org.apache.avalon.framework.logger.Logger;
@@ -110,7 +112,7 @@
/**
* The root of the formatting object tree
*/
-protected FONode rootFObj = null;
+protected Root rootFObj = null;
/**
* The class that handles formatting and rendering to a stream
@@ -120,6 +122,8 @@
private FOUserAgent userAgent;
+public Document document;
+
/**
* Default constructor
*/
@@ -290,7 +294,8 @@
+ be fo:root, not
+ fobj.getName()));
}
-rootFObj = fobj;
+rootFObj = (Root)fobj;
+rootFObj.setDocument(document);
} else {
currentFObj.addChild(fobj);
}
1.7 +2 -2 xml-fop/src/java/org/apache/fop/fo/FObjMixed.java
Index: FObjMixed.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FObjMixed.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- FObjMixed.java14 Aug 2003 07:42:58 - 1.6
+++ FObjMixed.java16 Aug 2003 06:43:51 - 1.7
@@ -104,8 +104,8 @@
if (textInfo == null) {
// Really only need one of these, but need to get fontInfo
// stored in propMgr for later use.
-propMgr.setFontInfo(fontInfo);
-textInfo = propMgr.getTextLayoutProps(fontInfo);
+propMgr.setFontInfo(getDocument());
+textInfo = propMgr.getTextLayoutProps(getDocument());
}
FOText ft = new FOText(data, start, length, textInfo, this);
1.7 +16 -16xml-fop/src/java/org/apache/fop/fo/PropertyManager.java
Index: PropertyManager.java
===
RCS file:
commons-io [WAS: gump build failed (trunk)]
Victor Mote wrote: BTW, there are some deprecation warnings coming from gump also. I haven't had a chance to look into them yet. They are related related to our dependency on jakarta-commons-io, which we will need to upgrade to get the warnings to disappear. Since this is a sandbox project, it doesn't have a nightly build, at least not one linked from the jakarta web site. Building it from scratch turns out to be non-trivial, at least for me. I'm just going to leave it alone for now. Jeremias, if you know how to get a convenient updated build, that would be a big help. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: commons-io [WAS: gump build failed (trunk)]
Commons IO is currently in a state of flux while it is being refactored. I think it is a bit premature to fix the deprecation warnings just now, and it doesn't hurt in HEAD's current state. I'll do the necessary changes when I feel that Commons IO is ready. Ok for you guys? I'll see what I can do about the nightly build, though. Sorry for not being around so much lately. Too many things cooking at the same time... On 16.08.2003 18:32:06 Victor Mote wrote: Victor Mote wrote: BTW, there are some deprecation warnings coming from gump also. I haven't had a chance to look into them yet. They are related related to our dependency on jakarta-commons-io, which we will need to upgrade to get the warnings to disappear. Since this is a sandbox project, it doesn't have a nightly build, at least not one linked from the jakarta web site. Building it from scratch turns out to be non-trivial, at least for me. I'm just going to leave it alone for now. Jeremias, if you know how to get a convenient updated build, that would be a big help. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Status report
Right here, monitoring but not having enough time to actively participate in coding. I saw your entry and had nothing to add. The suboptimal wording didn't occur to me. But as you said, it's a Wiki. Everyone can help improve. On 16.08.2003 18:53:28 J.Pietschmann wrote: Where are our PMC members?? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Status report
Jeremias Maerki wrote: Right here, Well, that's 50% :-) monitoring but not having enough time to actively participate in coding. I had more the heads-up for participation in preparation of the status report in mind... I'm lagging behind in coding myself. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: control/Document
--- Victor Mote [EMAIL PROTECTED] wrote: I mention this because I know that Glen is trying to get apps cleaned up. I think creation of control should help. From my perspective, apps is pretty well cleaned up now. (I'll try my luck at the properties and the AWTRenderer next.) Document also seems to fit well in the apps package (it encapsulates a Driver object, also it may be replacing Driver in the future). So unless it makes your coding easier, you may just want to place that class in apps and not bother with the Control package. (But I don't know how large you intend the Control package to get.) Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: commons-io [WAS: gump build failed (trunk)]
Jeremias Maerki wrote: Commons IO is currently in a state of flux while it is being refactored. I think it is a bit premature to fix the deprecation warnings just now, and it doesn't hurt in HEAD's current state. I'll do the necessary changes when I feel that Commons IO is ready. Ok for you guys? That works fine, as long as you guys don't change it from deprecated to not there. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: control/Document
Glen Mazza wrote: From my perspective, apps is pretty well cleaned up now. (I'll try my luck at the properties and the AWTRenderer next.) Peter has done some work on properties, but I am not clear on what the status of that is. If I understood, he was going to place the properties as fields directly in the class instead of as separate objects. That seemed to me like a Good Thing, as it seems to make everything lighter, smaller, and cleaner. But then I later got the impression that he was basically abandoning the FO Tree entirely in favor of his pull parsing, so I was pretty confused about all of it. I don't have a good feel for what the rest of the committers think about this. IMO, changes to properties would seem to be low priority, since it works. However, a reasonable case can be made that cleaning it up simplifies layout, which is very, very important. (Really, the tack I am on is an effort to segregate and simplify so that layout will be cleaner and more fun (?) to work on.) At the very least, please tell us what your plans are for properties. Document also seems to fit well in the apps package (it encapsulates a Driver object, also it may be replacing Driver in the future). So unless it makes I think of Driver as corresponding to my Session concept. Driver/Session potentially has a many-to-one relationship with Document. We have debated whether we want to allow that many-to-one relationship to actually exist, but IMO, whether we do or not, there is value in keeping the concepts separate. Document does store the Driver object, mostly as a reference. You can now use getDocument() from any FONode subclass to find the Document object, and therefore, you can also find the Driver object. There is a lot of refactoring to do in Driver and Document after I get everything bubbled up there that I want. Right now, I am just trying to avoid breaking anything (else). your coding easier, you may just want to place that class in apps and not bother with the Control package. (But I don't know how large you intend the Control package to get.) I'm don't care much which package it is in. I kind of thought that you and Jeremias were heading toward having apps only have command-line level and API stuff in it, and control is kind of the central clearing house that takes input from command-line or an embedded app, and runs it. Ideally control would have Driver/Session, Document, perhaps a RenderContext, and perhaps some Render control concepts. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
