Re: Unnesting properties and makers.
--- Finn Bock [EMAIL PROTECTED] wrote:
Does anyone know why we wrap the datatypes instances
in a property
instance? I think we could avoid the property
instance by having the
datatypes extends an AbstractProperty class which
implement a Property
interface:
public interface Property {
public Length getLength();
public Space getSpace();
...
}
[Glen Mazza]
Finn, just so I understand more here--what is the set
of methods that this interface would have? (You don't
have to give me a full enumeration if it's huge--but
let me know you determine them.) How many of them are
there--10 of them or 20 or 30 or ???
This is the full set, exactly the same which now exists in Property as
null methods.
public Length getLength();
public ColorType getColorType();
public CondLength getCondLength();
public LengthRange getLengthRange();
public LengthPair getLengthPair();
public Space getSpace();
public Keep getKeep();
public int getEnum();
public char getCharacter();
public Vector getList();
public Number getNumber();
public Numeric getNumeric();
public String getNCname();
public Object getObject();
public String getString();
The name of the returned compound property values would change according
to the new naming rule that we decide.
regards,
finn
Re: Unnesting properties and makers.
[Glen Mazza] I now understand what you're saying, and like the simplification you're suggesting. The current naming however, is probably preferable--the word Property figures quite highly in the spec! Do you have a problem remaining with it? Not at all, it is just that I though it would be confusing to rename the 'datatypes' classes to XXXProperty as they would conflict with the old XXXProperty classes, but it is only a problem when you compare before vs. after. If the change is done, the resulting XXXProperty classes will be completely consistent. For those (*)'ed datatypes, can't we get rid of the datatype instead by rolling that datatype into the equivalently named Property? In turn, have *those* Properties extend AbstractProperty as you suggest. Actually, I guess I'm just saying the same thing you're suggesting, except to use --Property instead of --Type for everything. Indeed. Which package should the resulting rolled datatype/property be placed in? My feeling says fop.datatypes (and the nested makers should be unnested and placed in fop.fo.properties). But that is a separate suggestion which does not have to be dealt with initially. Offhand, it's doesn't seem natural to go without Property objects--they are kept in the PropertyList and indexed by the property ID in that list. That would still be the case. Everything stored in the PropertyList implements the Property interface. But only a few of them would extend AbstractProperty, correct--or would you plan on having all do so? All of the properties would extend AbstractProperty. That way the properties get the default 'null' implementation of all the gettype methods. The only hard requirement is that all the properties implement the Property interface. Except that the code above should IMHO use if (prop.getLength() != null) to test for a length type instead of using instanceof. Well, instanceof is slower I believe, but better self-commenting. If you switch to this type of conditional for speed, just add a short comment of its purpose--here, to determine if we are working with an EnumProperty or a LengthProperty. (Another option, BTW, if you think it will cut down on buggy programming, is to have the classes implementing this Property interface supply unsupported interface methods a la Peter's Read-Only BitSet[1], i.e., throw exceptions. We can revisit this topic later if code errors are becoming a problem.) In most cases a NPE exception is throws immediately after the call to gettype, but an exception thrown from within the gettype could indeed carry more information about the cause of failure. I still like the null return and null test better than the alternatives tho. regards, finn
Re: Unnesting properties and makers.
Each of the typeType classes also implements the gettype methods
from Property so the layout must do exactly the same as it does now to
extract the right value:
propertyList.get(PR_INLINE_PROGRESSION_DIMENSION).
getLengthRange().getOptimum().getLength();
[Andreas L. Delmelle]
Hmmm... coming back to my recent question about the use of/access to the
background-color property: I somehow would feel much for further extending
the way the Common*Properties are handled. IIC, the calls like the above
should only happen in the background via the propMgr of the FObj, and not
become part of the public API.
I dunno. The spec clearly list which properties that apply for a element:
file:///d:/java/REC-xsl/slice6.html#fo_external-graphic
so it makes sense to find the same list of assignments in the layout
managers.
As a concrete example, in Layout, I would rather see something like:
private AreaDimensionProps adimProps;
...
protected void initProperties(PropertyManager propMgr) {
adimProps = propMgr.getAreaDimensionProps();
...
}
Yeah, if it make sense to add more groups of properties together (and it
seems that such a ipd,bpd pair make sense) I don't see a problem adding
that.
...
Length ipd = aProps.ipd;
Yes, except that it is a LengthRange property.
(maybe the latter can become more abstract
PropertyValue ipd = aProps.ipd; )
My gut feeling says no. Unless the property in question can take
non-LengthRange values (which ipd can not). The layoutmanagers should
resolve the property value as far as they can as early as they can IMHO.
regards,
finn
DO NOT REPLY [Bug 26434] New: - [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26434. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26434 [PATCH] unnesting Property.Maker and rollling datatypes into thier properties. Summary: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties. Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This patch is intended as inspiration and as an example of the discussion found here: http://marc.theaimsgroup.com/?l=fop-devm=107511296910230w=2 The patch includes the following: - unnests the Property.Maker classes. - moves the PropertyMakers into properties - Rolls the datatypes into the property classes. - Moves the property classes into datatypes. The patch moves files around into new packages but I have not been able to get a 'delete file' into the patch, so there is some files that must be manually deleted after applying the patch: src/java/org/apache/fop/datatypes/AutoLength.java src/java/org/apache/fop/datatypes/ColorType.java src/java/org/apache/fop/datatypes/CondLength.java src/java/org/apache/fop/datatypes/FixedLength.java src/java/org/apache/fop/datatypes/Keep.java src/java/org/apache/fop/datatypes/Length.java src/java/org/apache/fop/datatypes/LengthPair.java src/java/org/apache/fop/datatypes/LengthRange.java src/java/org/apache/fop/datatypes/MixedLength.java src/java/org/apache/fop/datatypes/PercentLength.java src/java/org/apache/fop/datatypes/Space.java src/java/org/apache/fop/fo/BorderWidthPropertyMaker.java src/java/org/apache/fop/fo/CharacterProperty.java src/java/org/apache/fop/fo/ColorTypeProperty.java src/java/org/apache/fop/fo/CompoundPropertyMaker.java src/java/org/apache/fop/fo/CondLengthProperty.java src/java/org/apache/fop/fo/CorrespondingPropertyMaker.java src/java/org/apache/fop/fo/DimensionPropertyMaker.java src/java/org/apache/fop/fo/EnumProperty.java src/java/org/apache/fop/fo/IndentPropertyMaker.java src/java/org/apache/fop/fo/KeepProperty.java src/java/org/apache/fop/fo/LengthPairProperty.java src/java/org/apache/fop/fo/LengthProperty.java src/java/org/apache/fop/fo/LengthRangeProperty.java src/java/org/apache/fop/fo/LineHeightPropertyMaker.java src/java/org/apache/fop/fo/ListProperty.java src/java/org/apache/fop/fo/NumberProperty.java src/java/org/apache/fop/fo/SpaceProperty.java src/java/org/apache/fop/fo/StringProperty.java
Re: PDF Transcoder patch
Glen Mazza wrote: I tried to do a complete switch from FOUserAgent to logger in the images package, was not able to (there are still other cases the FOUserAgent is actually being used.) Glen - I havent looked at this in detail, but my understanding of the FOUserAgent was the place holder for any user configuration, e.g. baseFontDir, baseImageDir, etc. So by changing all FOuserAgent arguments to loggers, are you excluding the possibility of code in the images package from accessing any user configuration, e.g. baseImageDir? Chris
DO NOT REPLY [Bug 26434] - [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26434. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26434 [PATCH] unnesting Property.Maker and rollling datatypes into thier properties. --- Additional Comments From [EMAIL PROTECTED] 2004-01-26 11:33 --- Created an attachment (id=10086) A unified patch against HEAD.
Re: Changing policy on minimum JDK requirements for HEAD
Peter B. West wrote: snip/ The 0.20 series is supported on 1.3, so an important question is: what is the expected timeframe for availability of 1.4 for those users who are currently restricted to 1.3? Vendors should be able to provide their users with some indication of this. We should at least ask the question in any survey of users. An ancillary question is: what is the user's expected timeframe for migration? I think this is one of the key factors in deciding. It is very tempting to make the decision based on new APIs etc that make our lives easier, but make the lifes of our users much harder. Anyone who has worked in a large organisation will know: it is very difficult to upgrade the OS on a server (which is a pre-requiste for later JDKs on some platforms). Large companies tend to have request forms/processes just to copy a single file onto large servers/mainframes, let alone upgrading OS/JDKs. Chris
RTF: white-space-treatment and linefeed-treatment
Hello, i am currently working on support for white-space-treatment and linefeed-treatment for the RTF module. Of course i don't want to reinvent the wheel, so i tried wanted Block.handleWhiteSpace method to do the job. But when i read the text data which is passed to RtfHandler.characters there is no support for white-space-treatment and linefeed-treatment. The handleWhiteSpace method seems to process the text data at later time. If i loop through Block.children in RtfHandler.endBlock and look for FOText objects the text data is processed correctly. But unfortunately i need the text data in RtfHandler.characters - in RtfHandler.endBlock it's to late. I see following possibilities to solve this problem: (1) I re-implement support for white-space-treatment and linefeed-treatment in the RTF module and call this algorithm from RtfHandler.characters - independend of Block.handleWhiteSpace. (IMHO not a good idea) (2) I defer the processing of all inline-generating, text-containing FOs, and process them in RtfHandler.endBlock. (Maybe it could be difficult to determine when to defer processing and when not. For example i'll have to be carefull with nested fo:block's. Quite difficult.) (3) I defer the processing of all FOs until endPageSequence, and then loop recursively through all children and call startXXX and endXXX events explicitly. (Maybe the best solution. On one hand this would be a quite big revolution for just two properties, on the other hand maybe there are similar issues in future.) Any comments or opinions appreciated. Kind regards Peter Herweg
Re: PDF Transcoder patch
Chris, Certain packages of our project--in this case, the image package--are used both by the PDFTranscoder (a separate application, if you will) and the FOP application. The FOUserAgent is ultra-easy (?) to access from the FOP Application, but not-so-easy (and, also, not-so-relevant) for the PDFTranscoder. (We also have an SVGUserAgent, but I haven't researched it.) Most of the methods in image are requesting a FOUserAgent parameter, but are *only* using its logger once it gets it: ua.getLogger().warn(...); etc, etc. For several of those methods, I changed the input parameter from FOUserAgent to Logger. (Which is probably correct, if all a certain method needs is a logger, that's all it should get.) Code accessing those methods no longer send, say, myFOUserAgent, but myFOUserAgent.getLogger(). Thomas DeWeese of Batik, in doing PDF Transcoder work for us (or maybe something else graphics-related--I really don't understand most of that stuff ;) had trouble accessing the FOUserAgent from his code. I changed the signatures as above for the methods in question and created a logger instance for him to use in his calling method, fixing the problem. Should a method need FOUserAgent--and I couldn't find any in Image *directly* using it (a call to the SVG package did, however, but I don't know if that SVG package also just wanted its logger, I stopped researching to that degree)--well, then, we can't change its signature. My inclination is to make FOUserAgent a FOP-only critter and save the PDFTranscoder from it where possible. I.e., in the example below of needing an image baseDir, sending the foUserAgent.getImageBaseDir() as a parameter instead, so Thomas can just send myImageBaseDir to the same method for his transcoder work, without needing to bother with an FOUserAgent. Glen --- Chris Bowditch [EMAIL PROTECTED] wrote: Glen Mazza wrote: I tried to do a complete switch from FOUserAgent to logger in the images package, was not able to (there are still other cases the FOUserAgent is actually being used.) Glen - I havent looked at this in detail, but my understanding of the FOUserAgent was the place holder for any user configuration, e.g. baseFontDir, baseImageDir, etc. So by changing all FOuserAgent arguments to loggers, are you excluding the possibility of code in the images package from accessing any user configuration, e.g. baseImageDir? Chris __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Re: Unnesting properties and makers.
--- Finn Bock [EMAIL PROTECTED] wrote: however, is probably preferable--the word Property figures quite highly in the spec! Do you have a problem remaining with it? Not at all, it is just that I though it would be Good--we can stick with Property then. Indeed. Which package should the resulting rolled datatype/property be placed in? My feeling says fop.datatypes (and the nested makers should be unnested and placed in fop.fo.properties). But that is a separate suggestion which does not have to be dealt with initially. Yes, it doesn't matter right now--do what you think is best, we can rearrange them later if needed. Unnesting is fine--I particularly liked the new PropertyMaker class. One issue--before I forget--in the FOPropertyMapping, for the colors, we have a huge set of genericColor.addKeyword(blue, #); genericColor.addKeyword(red, #); etc... etc... I just noticed, however, that the datatypes.ColorType class already has color types predefined within it. Do we really need to have both? I think we can get rid of one or the other, correct? I still like the null return and null test better than the alternatives tho. OK. Sounds good. The patch looks fine to me. Thanks, Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Re: PDF Transcoder patch
Glen Mazza wrote: Thanks for taking the time to explain Glen. What youve said is mostly as I understood it. Some comments below. snip/ The FOUserAgent is ultra-easy (?) to access from the FOP Application, but not-so-easy (and, also, not-so-relevant) for the PDFTranscoder. (We also have an SVGUserAgent, but I haven't researched it.) Opportunity for a UserAgent super class? (see below) snip/ Should a method need FOUserAgent--and I couldn't find any in Image *directly* using it (a call to the SVG package did, however, but I don't know if that SVG package also just wanted its logger, I stopped researching to that degree)--well, then, we can't change its signature. I wouldnt expect you to find any instances of FOUserAgent being used at this time, because AFAIK configuration hasnt yet been implemented in HEAD. I am just trying to make sure that before we delete all references to FOUserAgent from the images package that weve considered whether the images package will need access to configuration when its implemented in HEAD. Presumably such an implementation would start with a basic set of user config settings, and be expanded over time according to user demands. My inclination is to make FOUserAgent a FOP-only critter and save the PDFTranscoder from it where possible. I.e., in the example below of needing an image baseDir, sending the foUserAgent.getImageBaseDir() as a parameter instead, so Thomas can just send myImageBaseDir to the same method for his transcoder work, without needing to bother with an FOUserAgent. I dont have any particular interest in this area, I just dont want to undo something that we may need to redo later. If you think its a non issue, then thats fair enough, just as long as its been thought through. Thanks, Chris
RE: Unnesting properties and makers.
-Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] [Andreas L. Delmelle] Hmmm... coming back to my recent question about the use of/access to the background-color property: I somehow would feel much for further extending the way the Common*Properties are handled. IIC, the calls like the above should only happen in the background via the propMgr of the FObj, and not become part of the public API. I dunno. The spec clearly list which properties that apply for a element: file:///d:/java/REC-xsl/slice6.html#fo_external-graphic (Off-topic: Finn, I don't think I have access to your d:-drive ;) ) so it makes sense to find the same list of assignments in the layout managers. Indeed it does, but I don't think Layout needs them all, neither does it need them in their initial 'states' (don't really know what other word to use for this...). For instance: fo:block background-color=inherited-property-value(color) ... The layout manager doesn't need _this_ value of the property, it needs the actual ColorType (so I guess I basically agree with your comment about the more abstract version). snip / Yeah, if it make sense to add more groups of properties together (and it seems that such a ipd,bpd pair make sense) I don't see a problem adding that. I just think this will lead to an API that's a bit clearer, cleaner and so, in the long run, easier to manage and maintain. I don't really know whether the Common*Properties were separated out because they are, well, common, and it's more efficient for them to be treated as a bundle. Maybe it was originally the intention of creating property groups along the groups in which they are divided in the spec (see http://xml.apache.org/fop/compliance.html)? AFAICT the basic framework is already present to tie the 'propertyList.get(...)'-calls all together in the PropertyManager. If it is decided at a later point that something needs to be added/modified WRT Properties, this could avoid having to modify numerous corresponding propertyList.get()-calls in all related FObj's / LM's / Areas. ( Referring to the string-int conversion, and the hours Glen has spent to trace the calls and replace the constant-names... ) ... Length ipd = aProps.ipd; Yes, except that it is a LengthRange property. Ouch! My mistake :) Cheers, Andreas
Re: Unnesting properties and makers.
Glen Mazza wrote: Well, instanceof is slower I believe, but better self-commenting. Instanceof is exactly as fast as a simple function call after warm-up. J.Pietschmann
Re: RTF: white-space-treatment and linefeed-treatment
Peter Herweg wrote: (2) I defer the processing of all inline-generating, text-containing FOs, and process them in RtfHandler.endBlock. I'd say start with this option, although I'm starting to believe we could and should move whitespace processing to before the invocation of the structure renderer's character event call. You still have to delay some output because space before/after a line break must be stripped for many settings. What are the difficulties for nested blocks? J.Pietschmann
Re: Unnesting properties and makers.
Glen Mazza wrote:
Well, instanceof is slower I believe, but better
self-commenting.
[J.Pietschmann]
Instanceof is exactly as fast as a simple function call
after warm-up.
That is not what I remembered, so I made a small test program and ran it
with 3 different versions of jdk:
[/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x
false method call 160
true method call 170
false instanceof 581
true instanceof 581
[/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x
false method call 16614
true method call 881
false instanceof 1162
true instanceof 2083
[/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x
false method call 581
true method call 661
false instanceof 2153
true instanceof 2734
I really don't know what to conclude from this test, but at least I'm
glad I didn't mentioned performance as the reason why I prefer the
gettype way of testing for subclasses.
I'm surprised of the slow performance of calling non-overridden methods
in jdk1.3.1. I don't have any explanation for that.
regards,
finn
import java.io.*;
import java.net.*;
public class x {
public static final int ITERS = 1;
public static void main(String[] args) throws Exception {
Prop prop = new Prop();
Prop stringprop = new StringProp();
// Warm up the JIT.
testCall(prop);
testInstanceOf(prop);
long now;
now = System.currentTimeMillis();
testCall(prop);
System.out.println(false method call +
(System.currentTimeMillis() - now));
now = System.currentTimeMillis();
testCall(stringprop);
System.out.println(true method call +
(System.currentTimeMillis() - now));
now = System.currentTimeMillis();
testInstanceOf(prop);
System.out.println(false instanceof +
(System.currentTimeMillis() - now));
now = System.currentTimeMillis();
testInstanceOf(stringprop);
System.out.println(true instanceof +
(System.currentTimeMillis() - now));
}
public static void testInstanceOf(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop.getString() != null;
}
}
public static void testCall(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop instanceof StringProp;
}
}
public static class Prop {
public String getString() {
return null;
}
}
public static class StringProp extends Prop{
String value = a string;
public String getString() {
return value;
}
}
}
RE: Unnesting properties and makers.
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
public static void testInstanceOf(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop.getString() != null;
}
}
public static void testCall(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop instanceof StringProp;
}
}
I'd swap either the method names or the contained expressions to get
dependable results (typo? Don't know if it's exactly the same code you ran
to get the test-results... or am I missing the point? --happens all too
often, I'm afraid.)
Cheers,
Andreas
Re: Unnesting properties and makers.
[Andreas L. Delmelle]
snip /
public static void testInstanceOf(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop.getString() != null;
}
}
public static void testCall(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop instanceof StringProp;
}
}
I'd swap either the method names or the contained expressions to get
dependable results (typo?
Yeah, an embarrassing copypaste bug. Thanks for catching it. The result
is then:
[/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x
false method call 581
true method call 581
false instanceof 160
true instanceof 170
[/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x
false method call 1272
true method call 2304
false instanceof 17945
true instanceof 912
[/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x
false method call 2154
true method call 2754
false instanceof 590
true instanceof 651
regards,
finn
Re: Unnesting properties and makers.
file:///d:/java/REC-xsl/slice6.html#fo_external-graphic [Andreas L. Delmelle] (Off-topic: Finn, I don't think I have access to your d:-drive ;) ) I hope not :-0 . Sorry about that. Yeah, if it make sense to add more groups of properties together (and it seems that such a ipd,bpd pair make sense) I don't see a problem adding that. I just think this will lead to an API that's a bit clearer, cleaner and so, in the long run, easier to manage and maintain. I don't really know whether the Common*Properties were separated out because they are, well, common, and it's more efficient for them to be treated as a bundle. Maybe it was originally the intention of creating property groups along the groups in which they are divided in the spec (see http://xml.apache.org/fop/compliance.html)? I don't know what the original intention was either but from the no-longer-used setup() methods in the flow objects like fo.flow.Block it looks like somebody once wanted the list of properties from the spec to be represented in the code. But that should not prevent us from doing it differently. regards, finn
Re: Unnesting properties and makers.
Finn Bock wrote:
Instanceof is exactly as fast as a simple function call
after warm-up.
That is not what I remembered,
[Snip]
I'm surprised. I made some measurements with a JDK 1.3.0,
with ~50 warm-up cycles to give HotSpot something to
optimize, and vaguely remembered instanceof was slightly
faster (~1%) than a foo(){return true;}. It may have
something to do with the test setup. I wouldn't rule out
I tested in a class without inheritance :-)
J.Pietschmann
Re: Comments on the changes to the property subsystem
On Sun, Jan 25, 2004 at 11:38:14PM +0100, Finn Bock wrote: [Simon Pepping] I have just catched up with the massive changes to the property system. Allow me to share a few observations: Thanks for your comments. How do you otherwise think it compares to the previous generated property makers? I could not recall how it was done before the patch. My notes only describe FOElementMapping, and I have not searched back in CVS. I find the set of Makers as done in FOElementMapping quite baroque. The current FOPropertyMapping is quite concise and elegant. On the other hand, I am a supporter of generating code from a description of base data in an XML file, and so saw a good side to the old method as well. I have not studied it in detail though. 1. If I see correctly, PropertySets is not yet used. Correct. Its intended use is when we, at some point in the future, want to store more than just the specified properties in the FObjs. PropertyList is still a HashMap keyed on property name. Is this waiting for some other changes to be made? Yes. Either PropertyList should have a Property[] array indexed directly by the propId or the HashMap should be keyed by an Integer object with the same value as the propId: super.get(integerArray[propId]); where integerArray is initialized as: integerArray[1] = new Integer(1); integerArray[2] = new Integer(2); ... Which of these it will be depends on how much information we decide to store in the Fobj. Your patch mentions the sparse array PropertyList.values for this purpose. You made much effort to construct it. A propos, the loop in PropertySets.initialize is not easily understood; I needed the explanation you gave in an email to understand it. It would be good to add an explanation to the code. If it helps, this is how it documented it in my own notes: 'For each FO type the BitSet of allowed properties is merged with the BitSet of allowed properties of its possible direct children. When for any FO type the mergeContent subroutine modifies its BitSet, it sets the boolean variable 'loop' to true to signal that another iteration of the loop is required. By iterating over the loop until no further modifications are made, one makes sure that the merging process propagates from below to the top, that is, from any FO type to its farthest possible ancestor. This ensures that every FO type registers the allowed properties of itself and of all FO types that may ever appear in its subtree.' I think the name 'modified' or 'dirty' for the loop variable would be more descriptive. 2. In FOPropertyMapping the word 'generic' is used in two different senses: in s_generics and getGenericMappings() on the one hand, and in genericBoolean etc., createGenerics() and useGeneric() on the other hand. This may be confusing. One might e.g. be tempted to think that s_generics contains the objects genericXxx only, which is not the case. You are absolutely correct. I've took the names from the code which existed at the time. I'm also terrible at naming things so other suggestions will be welcome. I suggest that we rename s_generics and getGenericMappings to s_fomapping and getFoMappings because they deal with the properties from the xsl:fo spec. It seems indeed best to rename these two. OTOH, getGenericMappings is the only symbol that is used by other classes. But because it is probably used only once, in FObj, it is not a problem to rename it. s_generics is a mapping of propId to Property.Maker, so it should be called something like PropertyMappings, or PropertyMakers (what does s_ stand for?). FO is very general, it could equally be used for element mappings. 3. getGenericMappings rebuilds s_generics every time it is called. In the current code it seems to be called only once, by FObj when the class is loaded. Would it not be better if getGenericMappings itself would ensure that the array is built only once? Yes, but I would like to take the question a bit further and ask where such information should be cached? Storing it in static variables caches it in the classloader which makes it difficult to control the release of the memory. Perhaps it would be better to store the information in the Driver or FOUserAgent, IOW to put the caching under user control. If caching at the classloader level is the best way to do it, then it makes perfect sense to do what you suggest. I agree with Glen's reply. This is information which the application needs to hold only once, and which may persist. The user has nothing to do with this mapping. Current FOP interleaves FOtree building with area tree building and rendering; only after the last pagesequence FO node has been built could it be released (or does area tree building access the makers as well, for non-resolved properties?), which provides hardly any gain; in runs with several documents it is even a loss. I wonder why FObj makes
RE: Unnesting properties and makers.
-Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] The result is then: [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x false method call 581 true method call 581 false instanceof 160 true instanceof 170 [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x false method call 1272 true method call 2304 false instanceof 17945 true instanceof 912 [/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x false method call 2154 true method call 2754 false instanceof 590 true instanceof 651 Very, very interesting... Java's OO-optimization at its best (except for 1.3)! After all, it shouldn't be *that* surprising that an accessor-method-call generates more overhead than a test for class-membership (but what if the class in question is not yet loaded at time? Not that this should occur a lot...) Cheers, Andreas
RE: Unnesting properties and makers.
On Mon, 2004-01-26 at 17:45, Andreas L. Delmelle wrote: -Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] The result is then: [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x false method call 581 true method call 581 false instanceof 160 true instanceof 170 [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x false method call 1272 true method call 2304 false instanceof 17945 true instanceof 912 [/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x false method call 2154 true method call 2754 false instanceof 590 true instanceof 651 Very, very interesting... When did the choice of JVM (java -client | java -server) appear ? Wasn't it 1.3 ? -- John Austin [EMAIL PROTECTED]
Re: Unnesting properties and makers.
J.Pietschmann wrote: Glen Mazza wrote: Well, instanceof is slower I believe, but better self-commenting. Instanceof is exactly as fast as a simple function call after warm-up. That's very useful to know. instanceof has had a very bad press. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Unnesting properties and makers.
On Mon, 2004-01-26 at 17:45, Andreas L. Delmelle wrote: -Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] The result is then: [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x false method call 581 true method call 581 false instanceof 160 true instanceof 170 [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x false method call 1272 true method call 2304 false instanceof 17945 true instanceof 912 [/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x false method call 2154 true method call 2754 false instanceof 590 true instanceof 651 Very, very interesting... Java's OO-optimization at its best (except for 1.3)! After all, it shouldn't be *that* surprising that an accessor-method-call generates more overhead than a test for class-membership (but what if the class in question is not yet loaded at time? Not that this should occur a lot...) So I copied that program and ran it on my RH 9 system. Got the following results. I am just quoting the results here: Note that the default JVM is -client or HotSpot ... [EMAIL PROTECTED] foptest]$ java -classpath . x false method call 998 true method call 1001 false instanceof 3008 true instanceof 4119 [EMAIL PROTECTED] foptest]$ java -server -classpath . x false method call 1 true method call 0 false instanceof 0 true instanceof 4822 [EMAIL PROTECTED] foptest]$ java -server x false method call 1 true method call 0 false instanceof 0 true instanceof 4784 java version 1.4.2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) H. -- John Austin [EMAIL PROTECTED]
Re: Unnesting properties and makers.
Finn Bock wrote: [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x false method call 581 true method call 581 false instanceof 160 true instanceof 170 [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x false method call 1272 true method call 2304 false instanceof 17945 true instanceof 912 [/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x false method call 2154 true method call 2754 false instanceof 590 true instanceof 651 These appear to be running on the same system. It's good news for instanceof, but what startles me is the performance of 1.2.2 relative to 1.4.2_02 (and, of course, 1.3.1_03. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination FoPageSequenceMaster.java
pbwest 2004/01/26 18:06:53
Modified:src/java/org/apache/fop/fo/pagination Tag:
FOP_0-20-0_Alt-Design FoPageSequenceMaster.java
Log:
Updated license to 2.0.
Other tidying up.
Revision ChangesPath
No revision
No revision
1.1.2.7 +18 -58
xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoPageSequenceMaster.java
Index: FoPageSequenceMaster.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoPageSequenceMaster.java,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -u -r1.1.2.6 -r1.1.2.7
--- FoPageSequenceMaster.java 20 Jan 2004 05:45:54 - 1.1.2.6
+++ FoPageSequenceMaster.java 27 Jan 2004 02:06:53 - 1.1.2.7
@@ -1,55 +1,20 @@
/*
- * $Id$
- *
- *
- * The Apache Software License, Version 1.1
- *
- *
- * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without modifica-
- * tion, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- *
- * 3. The end-user documentation included with the redistribution, if any, must
- *include the following acknowledgment: This product includes software
- *developed by the Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself, if
- *and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names FOP and Apache Software Foundation must not be used to
- *endorse or promote products derived from this software without prior
- *written permission. For written permission, please contact
- *[EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache, nor may
- *Apache appear in their name, without prior written permission of the
- *Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * This software consists of voluntary contributions made by many individuals
- * on behalf of the Apache Software Foundation and was originally created by
- * James Tauber [EMAIL PROTECTED]. For more information on the Apache
- * Software Foundation, please see http://www.apache.org/.
+ Copyright 2004 The Apache Software Foundation.
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
*
- *
- * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
+ * $Id$
*/
package org.apache.fop.fo.pagination;
@@ -75,6 +40,8 @@
* children of fo:layout-master-set FOs. Their contents are specified by
* (single-page-master-reference|repeatable-page-master-reference
*|repeatable-page-master-alternatives)+
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
*/
public class FoPageSequenceMaster extends FONode {
@@ -236,17 +203,12 @@
if (ev ==
cvs commit: xml-fop/src/java/org/apache/fop/datastructs Tree.java
pbwest 2004/01/26 15:07:11
Modified:src/java/org/apache/fop/datastructs Tag:
FOP_0-20-0_Alt-Design Tree.java
Log:
Removed references to modCount, used for
ConcurrentModificationException detection. Removed
references to the setting of the containing Tree instance in
Nodes.
Updated license to 2.0.
Revision ChangesPath
No revision
No revision
1.1.2.2 +16 -106 xml-fop/src/java/org/apache/fop/datastructs/Attic/Tree.java
Index: Tree.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datastructs/Attic/Tree.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Tree.java 5 Jul 2003 19:06:35 - 1.1.2.1
+++ Tree.java 26 Jan 2004 23:07:11 - 1.1.2.2
@@ -1,55 +1,19 @@
/*
+ Copyright 2004 The Apache Software Foundation.
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
* $Id$
- *
- *
- *
- * The Apache Software License, Version 1.1
- *
- *
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without modifica-
- * tion, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- *
- * 3. The end-user documentation included with the redistribution, if any, must
- *include the following acknowledgment: This product includes software
- *developed by the Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself, if
- *and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names FOP and Apache Software Foundation must not be used to
- *endorse or promote products derived from this software without prior
- *written permission. For written permission, please contact
- *[EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache, nor may
- *Apache appear in their name, without prior written permission of the
- *Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * This software consists of voluntary contributions made by many individuals
- * on behalf of the Apache Software Foundation and was originally created by
- * James Tauber [EMAIL PROTECTED]. For more information on the Apache
- * Software Foundation, please see http://www.apache.org/.
- *
- *
*/
package org.apache.fop.datastructs;
@@ -74,18 +38,6 @@
public class Tree {
/**
- * The number of times the tree has been istructurally modified/i.
- * See the discussion of the ttmodCount/tt field in
- * ttAbstractList/tt.
- */
-protected int modCount = 0;
-
-/**
- * Count of the nodes in this tree.
- */
-//protected int nodeCount = 0;
-
-/**
* The root node of this tree.
*/
cvs commit: xml-fop/src/java/org/apache/fop/datastructs TNode.java
pbwest 2004/01/26 15:19:06
Modified:src/java/org/apache/fop/datastructs Tag:
FOP_0-20-0_Alt-Design TNode.java
Log:
Changes to accommodate new Tree and Node.
Updates license to 2.0.
Revision ChangesPath
No revision
No revision
1.1.2.2 +28 -72xml-fop/src/java/org/apache/fop/datastructs/Attic/TNode.java
Index: TNode.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datastructs/Attic/TNode.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- TNode.java5 Jul 2003 19:06:35 - 1.1.2.1
+++ TNode.java26 Jan 2004 23:19:06 - 1.1.2.2
@@ -1,59 +1,18 @@
/*
- * TNode.java
- *
- * Created: Sat Oct 27 13:44:34 2001
- *
- *
- *
- * The Apache Software License, Version 1.1
- *
- *
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without modifica-
- * tion, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- *
- * 3. The end-user documentation included with the redistribution, if any, must
- *include the following acknowledgment: This product includes software
- *developed by the Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself, if
- *and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names FOP and Apache Software Foundation must not be used to
- *endorse or promote products derived from this software without prior
- *written permission. For written permission, please contact
- *[EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache, nor may
- *Apache appear in their name, without prior written permission of the
- *Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * This software consists of voluntary contributions made by many individuals
- * on behalf of the Apache Software Foundation and was originally created by
- * James Tauber [EMAIL PROTECTED]. For more information on the Apache
- * Software Foundation, please see http://www.apache.org/.
- *
- *
- * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
- * @version $Revision$ $Name$
+ Copyright 2004 The Apache Software Foundation.
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
*/
package org.apache.fop.datastructs;
@@ -62,42 +21,39 @@
/**
* A testbed for ttNode/tt.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
+ * @version $Revision$ $Name$
*/
public class TNode extends Node {
private Object content = null;
-public TNode (Tree tree) throws TreeException {
-super(tree);
+public TNode () {
+super();
}
-public
cvs commit: xml-fop/src/java/org/apache/fop/fo FOTree.java
pbwest 2004/01/26 18:01:17
Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FOTree.java
Log:
Updated license to 2.0.
Changed PreOrder arguments to match changes to Node.
Revision ChangesPath
No revision
No revision
1.1.2.5 +20 -55xml-fop/src/java/org/apache/fop/fo/Attic/FOTree.java
Index: FOTree.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Attic/FOTree.java,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -u -r1.1.2.4 -r1.1.2.5
--- FOTree.java 20 Jan 2004 05:45:55 - 1.1.2.4
+++ FOTree.java 27 Jan 2004 02:01:17 - 1.1.2.5
@@ -1,58 +1,20 @@
/*
+ Copyright 2004 The Apache Software Foundation.
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
* $Id$
- *
- *
- * The Apache Software License, Version 1.1
- *
- *
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without modifica-
- * tion, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- *
- * 3. The end-user documentation included with the redistribution, if any, must
- *include the following acknowledgment: This product includes software
- *developed by the Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself, if
- *and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names FOP and Apache Software Foundation must not be used to
- *endorse or promote products derived from this software without prior
- *written permission. For written permission, please contact
- *[EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache, nor may
- *Apache appear in their name, without prior written permission of the
- *Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * This software consists of voluntary contributions made by many individuals
- * on behalf of the Apache Software Foundation and was originally created by
- * James Tauber [EMAIL PROTECTED]. For more information on the Apache
- * Software Foundation, please see http://www.apache.org/.
- *
- *
* Created: Thu Aug 2 20:29:57 2001
- *
- * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
- * @version $Id$
*/
package org.apache.fop.fo;
@@ -69,6 +31,9 @@
/**
* ttFOTree/tt is the class that generates and maintains the FO Tree.
* It runs as a thread, so it implements the ttrun()/tt method.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
+ * @version $Id$
*/
public class FOTree extends Tree implements Runnable {
@@ -177,7 +142,7 @@
(System.currentTimeMillis() -
cvs commit: xml-fop/src/java/org/apache/fop/fo FoRoot.java
pbwest 2004/01/26 17:59:10 Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FoRoot.java Log: Updated license to 2.0. Revision ChangesPath No revision No revision 1.1.2.9 +17 -49xml-fop/src/java/org/apache/fop/fo/Attic/FoRoot.java Index: FoRoot.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Attic/FoRoot.java,v retrieving revision 1.1.2.8 retrieving revision 1.1.2.9 diff -u -r1.1.2.8 -r1.1.2.9 --- FoRoot.java 23 Jan 2004 12:47:58 - 1.1.2.8 +++ FoRoot.java 27 Jan 2004 01:59:10 - 1.1.2.9 @@ -1,50 +1,18 @@ /* - * - * The Apache Software License, Version 1.1 - * - * - * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without modifica- - * tion, are permitted provided that the following conditions are met: - * - * 1. Redistributions of source code must retain the above copyright notice, - *this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright notice, - *this list of conditions and the following disclaimer in the documentation - *and/or other materials provided with the distribution. - * - * 3. The end-user documentation included with the redistribution, if any, must - *include the following acknowledgment: This product includes software - *developed by the Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgment may appear in the software itself, if - *and wherever such third-party acknowledgments normally appear. - * - * 4. The names FOP and Apache Software Foundation must not be used to - *endorse or promote products derived from this software without prior - *written permission. For written permission, please contact - *[EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache, nor may - *Apache appear in their name, without prior written permission of the - *Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * This software consists of voluntary contributions made by many individuals - * on behalf of the Apache Software Foundation and was originally created by - * James Tauber [EMAIL PROTECTED]. For more information on the Apache - * Software Foundation, please see http://www.apache.org/. + Copyright 2004 The Apache Software Foundation. + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + * * $Id$ */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/datastructs TNodeTest.java
pbwest 2004/01/26 15:20:18
Modified:src/java/org/apache/fop/datastructs Tag:
FOP_0-20-0_Alt-Design TNodeTest.java
Log:
Changes to accommodate new TNode.
Updates license to 2.0.
Revision ChangesPath
No revision
No revision
1.1.2.2 +58 -96xml-fop/src/java/org/apache/fop/datastructs/Attic/TNodeTest.java
Index: TNodeTest.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/datastructs/Attic/TNodeTest.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- TNodeTest.java5 Jul 2003 19:06:35 - 1.1.2.1
+++ TNodeTest.java26 Jan 2004 23:20:18 - 1.1.2.2
@@ -1,59 +1,18 @@
/*
- * TNodeTest.java
- *
- * $Id$
- *
- *
- *
- * The Apache Software License, Version 1.1
- *
- *
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without modifica-
- * tion, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- *
- * 3. The end-user documentation included with the redistribution, if any, must
- *include the following acknowledgment: This product includes software
- *developed by the Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself, if
- *and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names FOP and Apache Software Foundation must not be used to
- *endorse or promote products derived from this software without prior
- *written permission. For written permission, please contact
- *[EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache, nor may
- *Apache appear in their name, without prior written permission of the
- *Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * This software consists of voluntary contributions made by many individuals
- * on behalf of the Apache Software Foundation and was originally created by
- * James Tauber [EMAIL PROTECTED]. For more information on the Apache
- * Software Foundation, please see http://www.apache.org/.
- *
- *
- * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
- * @version $Revision$ $Name$
+ Copyright 2004 The Apache Software Foundation.
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
*/
package org.apache.fop.datastructs;
@@ -61,6 +20,9 @@
/**
* A test class for ttTNode/tt.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
+ * @version $Revision$ $Name$
*/
public class TNodeTest{
@@ -69,20 +31,20 @@
public static void main(String[] args)
throws TreeException {
Tree tree = new Tree();
- TNode root = new TNode(tree, null, Root);
- TNode child1 = new TNode(tree,
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination PageSequenceMaster.java
pbwest 2004/01/26 18:07:49
Modified:src/java/org/apache/fop/fo/pagination Tag:
FOP_0-20-0_Alt-Design PageSequenceMaster.java
Log:
Updated license to 2.0.
Revision ChangesPath
No revision
No revision
1.1.2.2 +17 -50
xml-fop/src/java/org/apache/fop/fo/pagination/PageSequenceMaster.java
Index: PageSequenceMaster.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/PageSequenceMaster.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- PageSequenceMaster.java 5 Jul 2003 19:16:49 - 1.1.2.1
+++ PageSequenceMaster.java 27 Jan 2004 02:07:49 - 1.1.2.2
@@ -1,55 +1,19 @@
/*
+ Copyright 2004 The Apache Software Foundation.
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
* $Id$
- *
- *
- * The Apache Software License, Version 1.1
- *
- *
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without modifica-
- * tion, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- *
- * 3. The end-user documentation included with the redistribution, if any, must
- *include the following acknowledgment: This product includes software
- *developed by the Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself, if
- *and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names FOP and Apache Software Foundation must not be used to
- *endorse or promote products derived from this software without prior
- *written permission. For written permission, please contact
- *[EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache, nor may
- *Apache appear in their name, without prior written permission of the
- *Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * This software consists of voluntary contributions made by many individuals
- * on behalf of the Apache Software Foundation and was originally created by
- * James Tauber [EMAIL PROTECTED]. For more information on the Apache
- * Software Foundation, please see http://www.apache.org/.
- *
- *
- * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
*/
package org.apache.fop.fo.pagination;
@@ -81,6 +45,9 @@
* created which shares a name with its target isimple-page-master/i.
* This procedure results in a single common structure and manner of access
* for all page masters.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
+ * @version $Revision$ $Name$
*/
public class PageSequenceMaster {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination FoLayoutMasterSet.java
pbwest 2004/01/26 18:04:03 Modified:src/java/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design FoLayoutMasterSet.java Log: Updated license to 2.0. Return unmodifiable Map finalPageSequenceMasters in place of HashMap pageSequenceMasters. Revision ChangesPath No revision No revision 1.1.2.7 +34 -57 xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java Index: FoLayoutMasterSet.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java,v retrieving revision 1.1.2.6 retrieving revision 1.1.2.7 diff -u -r1.1.2.6 -r1.1.2.7 --- FoLayoutMasterSet.java20 Jan 2004 05:45:54 - 1.1.2.6 +++ FoLayoutMasterSet.java27 Jan 2004 02:04:03 - 1.1.2.7 @@ -1,63 +1,28 @@ /* + Copyright 2004 The Apache Software Foundation. + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + * $Id$ - * - * - * The Apache Software License, Version 1.1 - * - * - * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without modifica- - * tion, are permitted provided that the following conditions are met: - * - * 1. Redistributions of source code must retain the above copyright notice, - *this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright notice, - *this list of conditions and the following disclaimer in the documentation - *and/or other materials provided with the distribution. - * - * 3. The end-user documentation included with the redistribution, if any, must - *include the following acknowledgment: This product includes software - *developed by the Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgment may appear in the software itself, if - *and wherever such third-party acknowledgments normally appear. - * - * 4. The names FOP and Apache Software Foundation must not be used to - *endorse or promote products derived from this software without prior - *written permission. For written permission, please contact - *[EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache, nor may - *Apache appear in their name, without prior written permission of the - *Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * This software consists of voluntary contributions made by many individuals - * on behalf of the Apache Software Foundation and was originally created by - * James Tauber [EMAIL PROTECTED]. For more information on the Apache - * Software Foundation, please see http://www.apache.org/. - * - * - * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a - * @version $Revision$ $Name$ */ package org.apache.fop.fo.pagination; import java.util.Arrays; import java.util.Collection; +import java.util.Collections; import java.util.HashMap; import java.util.Iterator; +import java.util.Map; import java.util.NoSuchElementException; import org.apache.fop.apps.FOPException; @@ -74,6 +39,9 @@ * ttFoLayoutMasterSet/tt is the class which processes
cvs commit: xml-fop/src/java/org/apache/fop/fo FONode.java
pbwest 2004/01/26 17:17:21
Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FONode.java
Log:
Added direct foTree reference, instead of relying on
Tree reference in superclass.
Revision ChangesPath
No revision
No revision
1.2.2.12 +25 -53xml-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.2.2.11
retrieving revision 1.2.2.12
diff -u -r1.2.2.11 -r1.2.2.12
--- FONode.java 25 Jan 2004 04:40:34 - 1.2.2.11
+++ FONode.java 27 Jan 2004 01:17:21 - 1.2.2.12
@@ -1,57 +1,20 @@
/*
- *
- * The Apache Software License, Version 1.1
- *
- *
- * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without modifica-
- * tion, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- *
- * 3. The end-user documentation included with the redistribution, if any, must
- *include the following acknowledgment: This product includes software
- *developed by the Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowledgment may appear in the software itself, if
- *and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names FOP and Apache Software Foundation must not be used to
- *endorse or promote products derived from this software without prior
- *written permission. For written permission, please contact
- *[EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache, nor may
- *Apache appear in their name, without prior written permission of the
- *Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
- * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * This software consists of voluntary contributions made by many individuals
- * on behalf of the Apache Software Foundation and was originally created by
- * James Tauber [EMAIL PROTECTED]. For more information on the Apache
- * Software Foundation, please see http://www.apache.org/.
- *
- * FONode.java
+ Copyright 2004 The Apache Software Foundation.
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
* Created: Sat Nov 10 01:39:37 2001
* $Id$
- *
- * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
- * @version $Revision$ $Name$
*/
package org.apache.fop.fo;
@@ -82,6 +45,9 @@
/**
* Class for nodes in the FO tree.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
+ * @version $Revision$ $Name$
*/
public class FONode extends Node{
@@ -143,6 +109,11 @@
ROOT | DECLARATIONS | LAYOUT | SEQ_MASTER |
PAGESEQ | FLOW | STATIC | TITLE | MC_MARKER;
+/**
+ * The FO Tree
+ */
+protected final FOTree foTree;
