Apache Account Request: New FOP committer (Chris Bowditch)
Chris Bowditch has been voted in as new FOP committer. Please create a new account for him. +1: 6 +0: 0 -1: 0 Vote: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=572506 Full name: Chris Bowditch Preferred account name: cbowditch eMail-address: [EMAIL PROTECTED] Karma: xml-fop, xml-site The CLA should be on its way. Thanks! Jeremias Maerki
Apache Account Request: New FOP committer (Andreas L. Delmelle)
Andreas L. Delmelle has been voted in as new FOP committer. Please create a new account for him. +1: 5 +0: 0 -1: 0 (Note: There was a -1 that was later changed to a +1 with no -1s remaining.) Vote: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=572508 Full name: Andreas L. Delmelle Preferred account name: adelmelle (as andreas seems to be taken already) eMail-address: [EMAIL PROTECTED] Karma: xml-fop, xml-site The CLA should be on its way. Thanks! Jeremias Maerki
Re: Chris and Andreas: New committers, send your CLAs
Account requests sent. The accounts will be activated as soon as the CLAs arrive. andreas seems to be taken as username so I took the second choice (http://www.apache.org/~jim/committers.html). Finn, Chris and Andreas, welcome aboard! I'm glad to see FOP getting some speed again. Jeremias Maerki
[Bug 25480] - Experimental performance improvements.
[Glen in bugzilla] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480 I'm now looking at the changes to PropertySets.java (already applied) and PropertyList.java (only partly so) and have a few questions: 1.) For the new PropertyList constructor (in the patch), you appear to be duplicating the element ID argument, once as el, the other time as elementId--just to confirm, they are referring to the same thing (and hence one of them can be removed)? Yes, it is a silly leftover from my own conversion process. 2.) In PropertySets.java (already applied), method makeSparseIndices, you define indices[0] as: indices[0] = (short) (set.cardinality() + 1); Later, in PropertyList, you initialize the values array as follows: this.values = new Property[indices[0]]; I think we can then just use set.cardinality() in makeSparseIndices(), correct? (i.e., leave out the +1). No, the + 1 is a deliberate trick to handle unknown properties which should return a null value during lookup(). The other part of the trick is the int j = 1; in makeSpareIndices() which ensure that all the unknown properties in a indices array all have a value of '0' and all known properties has a value 0. For an element fo:bar which support 2 properties foo=21 and baz=137, the indices array has the values indices[21] = 1 indices[137] = 2 and all other values are 0. The PropertyList.values array then look like this: values[0] = null // always null. values[1] = reference to a 'foo' Property instance values[2] = reference to a 'baz' Property instance In the performance sensitive PropertyList.lookup(), the code doesn't have to test for properties that are unknown by fo:bar return values[indices[propertyName]]; because all unknown properties map to the values[0] index which always have a null value. -- 3.) PropertySets.java defines those properties which are valid for each FO--in PropertyList, the proposed implementation then uses that information to limit the properties that can be assigned to an FObj (i.e., only those defined as valid for it.) Am I correct here on this point? And it includes the properties that are valid for all the children element of each FO. That is what the large while loop does when it calls mergeContent. It keeps pulling the childrens properties into the parent and repeats doing it for all the FOs until no more properties can be pulled (yes, there has to be a better way of doing that). ... and do we also need to somehow additionally qualify *those* properties as valid for the FO but not directly relevant for it? I don't think so, and the patch doesn't do it. ProperttySets only return the set of properties that are valid for a FO. 4.) Finally, I'm too far removed from my C programming days to understand the math here: In the PropertyList constructor, you code this: this.specified = new int[(indices[0] 5) + 1]; (where indices[0] defines the number of properties valid for the FObj) Why the bitshifting 5 to the right? What does this accomplish--what is this shorthand for? The 32 bits that is stored in a int. See below. also, in putSpecified(int idx, Property value), you code this: specified[i 5] |= 1 (i 31); I'm not clear what this is doing either. What does putSpecified() do, and what's the point of the i 31 and the Or'ing? PropertList.specified is just a bitmap of the same size as values.length. All the shifting and masking is similar to what is done in java.util.BitSet, inlined in PropertyList for performance. putSpecified() insert a property in the array and set the specified bit to true. This is in contrast to the inherit() method which also inserts a property in the array but doesn't set the specified bit. The other put() method isn't used anymore. I also think that inlining the bitset implementation is going to far, but it does make a performance difference, so I included it in the patch. [Andreas L. Delmelle] IIC the initial strategy WRT inherited properties was to add methods to the FObj's to get these from their parent. I think the problem with this implementation is that, in the case of very large documents with deeply nested elements that inherit a property which is specified at the top-level, you would end up with one getter being dispatched to the parent's getter, and this in its turn being dispatched to yet another ancestor's getter (or Makers in case of Property creation)... In this case, however, I think you can't fully 'push' these onto the descendants, as this would lead to absurd storage-reqs for quite average-sized documents. OTOH, the inherited property value (resolved or unresolved) can indeed be supposed as available at parse time, because a parent is per se processed *before* any of its children. Absolutely correct, and I'm not at all sure that we should go to an array based storage of the properties in PropertyList, as I did in the patch. Using
DO NOT REPLY [Bug 25480] - [PATCH] Experimental performance improvements.
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=25480. 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=25480 [PATCH] Experimental performance improvements. --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 13:45 --- Further comments and discussions here: http://marc.theaimsgroup.com/?l=fop-devm=107369978306013w=2 http://marc.theaimsgroup.com/?l=fop-devm=107374163230526w=2
Re: multi page-sequence don't work for (XML+XSL) to PDF on the fly
Hi,
Can't you use multiple page-sequences instead of just creating one sequence
'interrupted' by the 'ctrlPage' template?
but How?
this template is more difficult since it is used in with a more
complicated XML like groupproduct/.../group..., the way that I
sent is for brevety to discover because ctrlPage don't work, for groups
I need print a header, followed by products, etc..., in original XSL i
use xalan extensions to count how many lines I used PDF.
A few remarks to help you on your way:
1. I can't seem to find the reason why you are placing the whole
fo:static-content into a separate template, since it is ... well, static
and it doesn't rely on the elements in the XML (unless something is
missing).
because, I reduced the code for brevety, then the static-content is for
groups case. sorry
2. In the ctrlPage template, you are testing for a position(): you could
also use XPath to select these, like
xsl:apply-templates select=product[(position() mod 3) = 0]
Then inside the product template, use
xsl:for-each select=preceding::product[position() 3] /
to grab the two preceding product nodes.
but for-each select don't put Xalan in DOM process? consumes more
memory? however I can't use position because the original XML is more
complex. (I use xalan extensions to control this). like this xsl:if
test=counter:read('ctLine') mod 3/xsl:if
3. Check our http://xml.apache.org/fop/resources.html page, among the books
and articles, there's a link to Dave Pawson's XSLT FAQ. Over there, you'll
find a lot of useful stuff (amongst others on grouping which I think you'll
find particularly helpful), so I'll bet you can work out a redesign which
affects only the XSL itself and leaves the other files alone.
If you really can't get any further, try posting your problem on Mulberry's
XSLT list. Warning: it's a quite high-traffic list, but the upside is that
the tips are 'highly-usable' ;)
Hope this helps!
Cheers,
Andreas
Thanks for tips
Clovis
cvs commit: xml-fop fop.bat
pbwest 2004/01/10 08:33:03 Added: .Tag: FOP_0-20-0_Alt-Design fop.bat Log: Adding execution support for WIndows from HEAD Revision ChangesPath No revision No revision 1.3.2.2 +19 -1 xml-fop/fop.bat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc RtfFootnote.java RtfTextrun.java
pherweg 2004/01/10 11:43:58
Modified:src/java/org/apache/fop/fo FOInputHandler.java
FOTreeHandler.java
src/java/org/apache/fop/render/mif MIFHandler.java
src/java/org/apache/fop/render/rtf RTFHandler.java
src/java/org/apache/fop/fo/flow Footnote.java
FootnoteBody.java
src/java/org/apache/fop/render/rtf/rtflib/rtfdoc
RtfTextrun.java
Added: src/java/org/apache/fop/render/rtf/rtflib/rtfdoc
RtfFootnote.java
Log:
added support for fo:footnote
Revision ChangesPath
1.13 +24 -3 xml-fop/src/java/org/apache/fop/fo/FOInputHandler.java
Index: FOInputHandler.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOInputHandler.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- FOInputHandler.java 1 Jan 2004 21:19:55 - 1.12
+++ FOInputHandler.java 10 Jan 2004 19:43:58 - 1.13
@@ -58,6 +58,8 @@
import org.apache.fop.fo.flow.BasicLink;
import org.apache.fop.fo.flow.Block;
import org.apache.fop.fo.flow.ExternalGraphic;
+import org.apache.fop.fo.flow.Footnote;
+import org.apache.fop.fo.flow.FootnoteBody;
import org.apache.fop.fo.flow.Inline;
import org.apache.fop.fo.flow.InstreamForeignObject;
import org.apache.fop.fo.flow.Leader;
@@ -365,9 +367,28 @@
public abstract void foreignObject(InstreamForeignObject ifo);
/**
- * Process a footnote.
+ * Process the start of a footnote.
+ * @param footnote Footnote that is starting
*/
-public abstract void footnote();
+public abstract void startFootnote(Footnote footnote);
+
+/**
+ * Process the ending of a footnote.
+ * @param footnote Footnote that is ending
+ */
+public abstract void endFootnote(Footnote footnote);
+
+/**
+ * Process the start of a footnote body.
+ * @param body FootnoteBody that is starting
+ */
+public abstract void startFootnoteBody(FootnoteBody body);
+
+/**
+ * Process the ending of a footnote body.
+ * @param body FootnoteBody that is ending
+ */
+public abstract void endFootnoteBody(FootnoteBody body);
/**
* Process a Leader.
1.12 +24 -4 xml-fop/src/java/org/apache/fop/fo/FOTreeHandler.java
Index: FOTreeHandler.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOTreeHandler.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- FOTreeHandler.java1 Jan 2004 21:19:55 - 1.11
+++ FOTreeHandler.java10 Jan 2004 19:43:58 - 1.12
@@ -62,6 +62,8 @@
import org.apache.fop.fo.flow.BasicLink;
import org.apache.fop.fo.flow.Block;
import org.apache.fop.fo.flow.ExternalGraphic;
+import org.apache.fop.fo.flow.Footnote;
+import org.apache.fop.fo.flow.FootnoteBody;
import org.apache.fop.fo.flow.InstreamForeignObject;
import org.apache.fop.fo.flow.Inline;
import org.apache.fop.fo.flow.Leader;
@@ -446,11 +448,29 @@
}
/**
- * @see org.apache.fop.fo.FOInputHandler#footnote()
+ * @see org.apache.fop.fo.FOInputHandler#startFootnote()
*/
-public void footnote() {
+public void startFootnote(Footnote footnote) {
}
-
+
+/**
+ * @see org.apache.fop.fo.FOInputHandler#endFootnote()
+ */
+public void endFootnote(Footnote footnote) {
+}
+
+/**
+ * @see org.apache.fop.fo.FOInputHandler#startFootnoteBody()
+ */
+public void startFootnoteBody(FootnoteBody body) {
+}
+
+/**
+ * @see org.apache.fop.fo.FOInputHandler#endFootnoteBody()
+ */
+public void endFootnoteBody(FootnoteBody body) {
+}
+
/**
* @see org.apache.fop.fo.FOInputHandler#leader(Leader)
*/
1.4 +24 -4 xml-fop/src/java/org/apache/fop/render/mif/MIFHandler.java
Index: MIFHandler.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/mif/MIFHandler.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MIFHandler.java 1 Jan 2004 21:19:55 - 1.3
+++ MIFHandler.java 10 Jan 2004 19:43:58 - 1.4
@@ -60,6 +60,8 @@
import org.apache.fop.fo.flow.BasicLink;
import org.apache.fop.fo.flow.Block;
import org.apache.fop.fo.flow.ExternalGraphic;
+import org.apache.fop.fo.flow.Footnote;
+import org.apache.fop.fo.flow.FootnoteBody;
import org.apache.fop.fo.flow.InstreamForeignObject;
import org.apache.fop.fo.flow.Inline;
cvs commit: xml-fop/src/java/org/apache/fop/fo Property.java PropertySets.java
gmazza 2004/01/10 12:40:07
Modified:src/codegen properties.xsl
src/java/org/apache/fop/datatypes
ToBeImplementedProperty.java
src/java/org/apache/fop/fo Property.java PropertySets.java
Log:
switch from Property.getPropName() to Property.getPropId(); comments added to
PropertySets.java to clarify makeSparseIndices() method.
Revision ChangesPath
1.31 +2 -2 xml-fop/src/codegen/properties.xsl
Index: properties.xsl
===
RCS file: /home/cvs/xml-fop/src/codegen/properties.xsl,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- properties.xsl9 Jan 2004 03:05:55 - 1.30
+++ properties.xsl10 Jan 2004 20:40:07 - 1.31
@@ -883,7 +883,7 @@
xsl:value-of select=key('shorthandref', $shprop)/datatype-parser/
xsl:text(listprop);
p = shparser.getValueForProperty(
-getPropName(), this, propertyList);
+getPropId(), this, propertyList);
}
}/xsl:text
/xsl:for-each
1.5 +1 -1
xml-fop/src/java/org/apache/fop/datatypes/ToBeImplementedProperty.java
Index: ToBeImplementedProperty.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/datatypes/ToBeImplementedProperty.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ToBeImplementedProperty.java 26 Dec 2003 23:41:47 - 1.4
+++ ToBeImplementedProperty.java 10 Jan 2004 20:40:07 - 1.5
@@ -69,7 +69,7 @@
}
ToBeImplementedProperty val =
-new ToBeImplementedProperty(getPropName());
+new ToBeImplementedProperty(getPropId());
return val;
}
}
1.15 +1 -1 xml-fop/src/java/org/apache/fop/fo/Property.java
Index: Property.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Property.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Property.java 9 Jan 2004 22:32:27 - 1.14
+++ Property.java 10 Jan 2004 20:40:07 - 1.15
@@ -81,7 +81,7 @@
/**
* @return the name of the property for this Maker
*/
-protected int getPropName() {
+protected int getPropId() {
return propId;
}
1.3 +18 -4 xml-fop/src/java/org/apache/fop/fo/PropertySets.java
Index: PropertySets.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/PropertySets.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- PropertySets.java 22 Dec 2003 23:23:05 - 1.2
+++ PropertySets.java 10 Jan 2004 20:40:07 - 1.3
@@ -1267,13 +1267,27 @@
}
+ /* These arrays, one for each formatting object, define the properties that
+* are valid for an FO and its children. The first element, indices[0],
+* will be used in PropertyList to define the size of the Property[] array
+* for the FObj (= the number of properties valid for the element + 1.)
+* Each other element of this array has a value of 0 if not supported by the FO,
+* 1-based index otherwise. This array will be used as a pointer to the
Property[]
+* array in PropertyList holding the valid properties for the FO.
+* i.e., fo.propList.values[indices[propId]] will refer to the correct Property
+* element if the property is valid for the FO, values[indices[invalPropId]] =
+* values[0] = NULL otherwise.
+*/
private static short[] makeSparseIndices(BitSet set) {
-short[] indices = new short[Constants.PROPERTY_COUNT];
+short[] indices = new short[Constants.PROPERTY_COUNT +1];
+
indices[0] = (short) (set.cardinality() + 1);
-int j = 1;
+
+int propIndex = 1;
for (int i = set.nextSetBit(0); i = 0; i = set.nextSetBit(i+1)) {
-indices[i] = (short) j++;
+indices[i] = (short) propIndex++;
}
+
return indices;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Compile error in HEAD
Hi, The code that I checked out this evening from CVS HEAD generates compile errors, for example, [javac] /fsd/source/xml-fop/build/gensrc/org/apache/fop/fo/properties/BorderBottomStyleMaker.java:21: cannot resolve symbol [javac] symbol : variable PR_BORDER_AFTER_STYLE [javac] location: interface org.apache.fop.fo.properties.Constants [javac] p= propertyList.getExplicitOrShorthand(propertyList.wmMap(Constants.PR_BORDER_AFTER_STYLE, Constants.PR_BORDER_AFTER_STYLE, Constants.PR_BORDER_END_STYLE)); [javac] ^ The cause is that the import section is not sufficient: package org.apache.fop.fo.properties; import org.apache.fop.fo.*; import org.apache.fop.apps.FOPException; With these import statements the compiler applies interface org.apache.fop.fo.properties.Constants instead of interface org.apache.fop.fo.Constants. An explicit statement import org.apache.fop.fo.Constants; should be added. I did it as follows: --- properties.xsl.~1.30.~ Sat Jan 10 20:02:04 2004 +++ properties.xsl Sat Jan 10 21:53:43 2004 @@ -329,7 +329,8 @@ import org.apache.fop.datatypes.*;/xsl:text /xsl:if xsl:text -import org.apache.fop.fo.*;/xsl:text +import org.apache.fop.fo.*; +import org.apache.fop.fo.Constants;/xsl:text xsl:if test=not( (./datatype and ./datatype[. ='List']) or ./class-name[.='GenericCondPadding'] @@ -338,10 +339,6 @@ xsl:text import org.apache.fop.apps.FOPException;/xsl:text /xsl:if - xsl:if test=.//enumeration and @type='generic' -xsl:text -import org.apache.fop.fo.Constants;/xsl:text -/xsl:if xsl:text public class /xsl:text The old code applies a precise test for the inclusion of the import statement. My change includes the import statement in all property makers. Not sure what a more precise test would look like, and if there can be any. Regards, Simon -- Simon Pepping email: [EMAIL PROTECTED] home page: http://www.leverkruid.nl public key: http://www.leverkruid.nl/personal/sp.asc fingerprint: E3BF 7295 9AA8 8B8A C01A 219D FAAC 088C 6B28 F549
Re: [Bug 25480] - Experimental performance improvements.
--- Finn Bock [EMAIL PROTECTED] wrote: 1.) For the new PropertyList constructor (in the patch), you appear to be duplicating the element ID argument, once as el, the other time as elementId--just to confirm, they are referring to the same thing (and hence one of them can be removed)? Yes, it is a silly leftover from my own conversion process. OK--BTW, what's your opinion on switching to FO Constants at this time? They probably will not give us the rate of return that property constants have; but there may be future indexing or processing advantages with them. I'm not strong one way or the other on them. One issue your brought up in the email below, was that of extension elements needing their own ID's dynamically: http://marc.theaimsgroup.com/?l=fop-devm=107182754300725w=2 Your solution in your email does not look difficult to implement, but as a simplification, how about just implementing getElementId() within FONode to query an new ID if its value is unintialized, say, -1, and to store that value with the FONode, *instead of* having each Extension FO's implement that query store function themselves? No, the + 1 is a deliberate trick to handle unknown properties which should return a null value during lookup(). snip/ Excellent--thanks for your full explanation--I understand it now, and have added comments to PropertySets.java to make it clearer for others who may also have questions. -- And it includes the properties that are valid for all the children element of each FO. That is what the large while loop does when it calls mergeContent. OK--but to satisfy the spec, we probably need to add a static boolean array for the properties, defining true/false of whether each property is inheritable. Because one can attach an inheritable property to any FO, regardless of whether or not it is relevant for it or its children, we don't want to report an error if the user chooses to do so--we can query this static array to determine that we should just ignore the property instead. I can probably help out with this--but I'll wait until later when 25873 is settled--we may end up having this information created anyway by then. , I've concluded that it would also be good design decision and I plan on updating patch 25873 to show that the Property.Maker can become simpler and easier to understand as well as faster. Looking forward to seeing it--I haven't had much time to look at 25873 yet. One possible way I see of simplifying the makers would be for them to no longer be a nested inner class of Property, but either part of the Property class itself or part of its own class. BTW, when you have write access available, let me know when you'd like me to step back, I'll happily retreat back to the renderers and let you take over the properties at your much faster rate of speed. Thanks, Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Compile error in HEAD
--- Simon Pepping [EMAIL PROTECTED] wrote: The cause is that the import section is not sufficient: package org.apache.fop.fo.properties; import org.apache.fop.fo.*; import org.apache.fop.apps.FOPException; With these import statements the compiler applies interface org.apache.fop.fo.properties.Constants instead of interface org.apache.fop.fo.Constants. Simon, I can't duplicate the problem on my machine but I think I see the issue: there is *no* more org.apache.fop.fo.properties.Constants interface anymore, it's been gone for a month or so. I think you just need to clear it out (delete the file), and make sure you have the newest build.xml--it is the script that formerly created that properties.Constants interface (but doesn't anymore). What I do before a full build is delete the BUILD directory, then type ant--this forces everything to be created from scratch. Another note: cvs update -dPC will overwrite and replace your work (actually, moves them to other files), but should remove unneeded files and also get you in sync with HEAD completely. An explicit statement import org.apache.fop.fo.Constants; should be added. I did it as follows: Yes, but the Eclipse warnings of unneeded imports drives Peter West and a few others crazy. If the above does not work, our only other solution would be a fully qualified import statement. Thanks always! Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Compile error in HEAD
--- Glen Mazza [EMAIL PROTECTED] wrote: Yes, but the Eclipse warnings of unneeded imports drives Peter West and a few others crazy. If the above does not work, our only other solution would be a fully qualified import statement. oops...I mean fully qualifying the Constants variables. Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: [Bug 25480] - Experimental performance improvements.
[Glen Mazza] ... what's your opinion on switching to FO Constants at this time? They probably will not give us the rate of return that property constants have; but there may be future indexing or processing advantages with them. I'm not strong one way or the other on them. Since then, you have removed the unused support for elementTable, which was the only place a FO constanst id was used. So I would delay the implementation of FO ids until that future arrives. http://marc.theaimsgroup.com/?l=fop-devm=107182754300725w=2 Your solution in your email does not look difficult to implement, but as a simplification, how about just implementing getElementId() within FONode to query an new ID if its value is unintialized, say, -1, and to store that value with the FONode, *instead of* having each Extension FO's implement that query store function themselves? That would also work, but the beauty of having each extension FO do the work is that it saves the size of an int (4 bytes) for each instance of a FONode. In my mail, the extension stores the id value in a static vrbl so it doesn't weight down every FONode object. And it includes the properties that are valid for all the children element of each FO. That is what the large while loop does when it calls mergeContent. OK--but to satisfy the spec, we probably need to add a static boolean array for the properties, defining true/false of whether each property is inheritable. Right, my patch stores that array in PropertyListBuilder.inherit. Because one can attach an inheritable property to any FO, regardless of whether or not it is relevant for it or its children, we don't want to report an error if the user chooses to do so--we can query this static array to determine that we should just ignore the property instead. A good point, my patch just reports an error when a property is specified that isn't relevant for the FO or any of its children. regards, finn
