addLayoutManager for 3rd part extension.

2003-09-11 Thread Finn Bock
Hi FOP'ers After the recent refactoring of addLayoutManager into the AddLMVisitor class, I can't quite see how an 3rd part extensions can control how its LM and the area tree nodes is created. I'm sure there are good reasons for the fo-tree separation and for using a Visitor pattern but it

Re: addLayoutManager for 3rd part extension.

2003-09-11 Thread Finn Bock
[Victor Mote] After the recent refactoring of addLayoutManager into the AddLMVisitor class, I can't quite see how an 3rd part extensions can control how its LM and the area tree nodes is created. It is good to know that there are people doing this. And it would be a disaster for me if this

Re: addLayoutManager for 3rd part extension.

2003-09-17 Thread Finn Bock
Victor Mote wrote: The LayoutManagerLS object is instantiated at line 584 of apps.Driver. I guess I don't know enough about your workflow to give you a good answer here. I thought from a previous post that you were modifying apps.Driver. Until now, is hasn't been necessary for me to modify

Re: addLayoutManager for 3rd part extension.

2003-09-18 Thread Finn Bock
Victor Mote wrote: What I did instead is commit changes that: 1. add Driver.getCurrentDocument() and Driver.setCurrentDocument() accessor methods 2. make the setting of the LayoutStrategy within Driver conditional on it being null I think you should be able to now drill down in a manner similar

Regression testing.

2003-10-09 Thread Finn Bock
Hi, I have a couple of small patches to the layout that I would like to submit but first I wanted to test them using your test suites. But I'm running into some problems that seems to indicate that I'm looking at the wrong test suite (or something). First I have created a directory

Re: String.intern() test and measurement

2003-12-02 Thread Finn Bock
I'm resending this mail since it hasn't yet shown up in the archives. I'm sorry about any duplicates. [John Austin] 4) Changed the handling of strings at the for-loop storing the attributes received from the parser in startElement( ... ) // Process attributes for (int i=0;

Re: String.intern() test and measurement

2003-12-02 Thread Finn Bock
[Glen Mazza] No I was actually thinking static final variables, my reference to enumerations was in a generic sense: public static final int PROPA = 1; public static final int PROPB = 2; public static final int PROPC = 3; That was also what I though you meant. Please accept my apology for

Re: String.intern() test and measurement

2003-12-02 Thread Finn Bock
[John Austin] I wondered how much chaining there has to be before performance gets really bad when I checked your program more closely. Your example program would produce external chains of length: 200/20011 ~ 100. I can see performance slow down well before 100.000 unique string are

Performance improvements.

2003-12-12 Thread Finn Bock
Hi, Inspired by the recent talk about optimizations, I have tried to look for low hanging fruits that can speed up FOP, and as I expected I did not find any silver bullets. On the other hand a series of smaller adjustments to the property handling has improved the total processing time about

Re: Performance improvements.

2003-12-13 Thread Finn Bock
On the other hand a series of smaller adjustments to the property handling has improved the total processing time about 10%. [Peter B. West] That's a better time improvement than I got with alt.design. The fact that I have extra overhead from the pull parsing may account for that. Perhaps, but

Re: (Victor et al) Re: Performance improvements.

2003-12-13 Thread Finn Bock
[Glen Mazza] Thanks, Finn and John Austin, for your efforts here. It's a pleasure. Victor, not to rush you, but how agreeable are you in general on switching to integer enumerations for FOP properties? (Given Alt-Design, Peter obviously approves.) I checked Alt-Design's PropNames.java[1] and

Re: (Victor et al) Re: Performance improvements.

2003-12-13 Thread Finn Bock
[J.Pietschmann] [snip] If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. I like the generation process as it allowed me to try out and experiment with different optimizations. I don't think that I realisticly could have added caching of

Re: (Victor et al) Re: Performance improvements.

2003-12-13 Thread Finn Bock
I like the generation process as it allowed me to try out and experiment with different optimizations. I don't think that I realisticly could have added caching of compound properties or changed the abs2rel/rel2abs code if I had to change the Maker classes manually. [J.Pietschmann] If its

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

2003-12-15 Thread Finn Bock
[Jeremias Maerki] I've removed the embedded Ant in HEAD. I rewrote build.bat and build.sh to call a separately installed Ant. Instructions will be given on the command-line if Ant cannot be found. Now that ant.jar has been removed, the project is slightly less friendly to eclipse since ant.jar

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

2003-12-16 Thread Finn Bock
[me] Now that ant.jar has been removed, the project is slightly less friendly to eclipse since ant.jar is required by the files in org.apache.fop.tools.anttasks. It is easily solved locally, I just wanted to point it out. [Peter B. West] Finn, I've been trying to find an Eclipse-clean way to

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java

2003-12-18 Thread Finn Bock
[Glen Mazza] It's been in that location for at least several months--it's just that we never saw it because it was autogenerated and never checked into CVS. (As for its location--it is used by the FO classes and it also has some FO constants and other enumerations in there, so it is OK remaining

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java

2003-12-19 Thread Finn Bock
Also, while I used fo:element constants in my experiment, it is clear to me that such an approach does not work well for extension elements. [Glen Mazza] Oh no--I hope you don't mean we have to revert to strings for those? No, not at all. It is just that the element id's for extensions must

Suppression of leading space

2003-12-19 Thread Finn Bock
Hi, I was taking a look at the issue where the text in a fo:block has a leading space added. I thought that by default, the initial spaces and LFs for such a block should be suppressed, but I can't quite find the place in the spec where it is defined. At least 3 properties comes into play:

Trying to use the NIST test suite.

2003-12-24 Thread Finn Bock
Hi, I was looking for xsl-fo test suites on the net and found http://www.w3.org/Style/XSL/TestSuite/ but for some reason all the test in the NIST zip file uses master-name instead of master-reference on the fo:page-sequence's. fo:page-sequence master-name=test-page-master Is there some

Re: Trying to use the NIST test suite.

2003-12-24 Thread Finn Bock
I was looking for xsl-fo test suites on the net and found http://www.w3.org/Style/XSL/TestSuite/ but for some reason all the test in the NIST zip file uses master-name instead of master-reference on the fo:page-sequence's. fo:page-sequence master-name=test-page-master [Andreas L. Delmelle]

Output from NIST test suite

2003-12-25 Thread Finn Bock
Hi, After 'fixing' the master-reference issue in my copy of the NIST test suite, I ran the tests against 0.20.5 and 1.0dev and merged the result side by side into a single .pdf file. You can download the result (1Mb) here: http://bckfnn-modules.sf.net/out-0.20.5-1.0.pdf For some reason

Re: Output from NIST test suite

2003-12-25 Thread Finn Bock
After 'fixing' the master-reference issue in my copy of the NIST test suite, I ran the tests against 0.20.5 and 1.0dev and merged the result side by side into a single .pdf file. [John Austin] Interesting technique. What tool do you use to make the side-by-side comparison ? This java program:

Which area rectangle does Block.height and Block.width specify?

2003-12-27 Thread Finn Bock
Hi, I was looking at some of the border issues and would like to ask for a little clarification of which of area rectangle that is described by Block.getHeight and Block.getWidth. http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#area-geo From looking at the layout managers it seems

Re: Which area rectangle does Block.height and Block.width specify?

2003-12-28 Thread Finn Bock
I was looking at some of the border issues and would like to ask for a little clarification of which of area rectangle that is described by Block.getHeight and Block.getWidth. [Keiron Liddle] I think the intention was that it is the allocation width and height, the content is then calculated

Re: (PMC'ers) give Finn write access...

2003-12-31 Thread Finn Bock
[Jeremias Maerki] Ok, Finn, what we need from you is your preferred unix username and the email address you would like to have uid@apache.org forwarded to. I have always done my open-source work under the 'bckfnn' handle. If possible, I would like to pick that as my unixname. Otherwise 'fb' or

Abandoning code-generated Property.Maker

2004-01-02 Thread Finn Bock
Hi, Inspired by a recent discussion about code-generated vs. manual maintained property maker classes, I've come up with an idea which I hope you will find interesting. The patch I've uploaded http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 which implement the idea, disables the

Re: Output from NIST test suite

2004-01-02 Thread Finn Bock
[Jeremias Maerki] You may also want to check the mailing list archives. Especially Joerg and I have discussed this a number of times. GhostScript paired with an image differ would be my favourite approach. Thanks for the tip about Ghostscript, I got it working and together with the NIST suite it

Re: Output from NIST test suite

2004-01-03 Thread Finn Bock
[Bernd Brandstetter] in your GhostScript installation there should also exist a gswin32c.exe which runs in console mode and therefore doesn't open a GUI window every time. And indeed there is. Boy, I feel stupid now. Thank you for the pointer. regards, finn

Re: Output from NIST test suite

2004-01-03 Thread Finn Bock
[Carmelo Montanez] Hi Folks: Somehow the final copy of the test suite was not uploaded to either our server at NIST or W3C. I uploaded a copy of the latest suite version to the following link: http://xw2k.sdct.itl.nist.gov/carmelo/formattingObjectsSuite123103.zip I will make sure it is at the

Regression caused by the string-int conversion

2004-01-05 Thread Finn Bock
--- PropertyList.java 5 Jan 2004 00:44:59 - 1.19 +++ PropertyList.java 5 Jan 2004 01:31:09 - 1.20 @@ -184,20 +184,11 @@ */ public Property getExplicitOrShorthand(int propId) { /* Handle request for one part of a compound property */ -

[Bug 25480] - Experimental performance improvements.

2004-01-10 Thread Finn Bock
[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

Re: [Bug 25480] - Experimental performance improvements.

2004-01-10 Thread Finn Bock
[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

Re: [Bug 25480] - Experimental performance improvements.

2004-01-12 Thread Finn Bock
[Glen] One thing I'm missing here, for Finn's design below: values[0] = null // always null. values[1] = reference to a 'foo' Property instance values[2] = reference to a 'baz' Property instance Can't we just have, say, values[1] refer to the parent's Property instance in cases where inheritance

Re: [Bug 25480] - Experimental performance improvements.

2004-01-13 Thread Finn Bock
[Glen Mazza] This sounds like it could be an excellent idea--a PropertyRepository (extending, of course, a DelmelleRepository (tm) ;) ) could be a very useful tool for FO Tree Building. Prior to creating any Property instance for any FO's array, we send the specs of the needed property to the

Re: [Bug 25480] - Experimental performance improvements.

2004-01-14 Thread Finn Bock
[me] 1) Only store the specified properties. That is what HEAD does now. 2) Put the relevant properties in a fast Property[] array and the remaining specified properties in a HashMap. For fo:root the result would be an array of size 1 for the 'media-usage' property. 3) Expect to store every

Re: [Bug 25480] - Experimental performance improvements.

2004-01-14 Thread Finn Bock
[Peter B. West] Alt-design (trying the hyphen for a while) takes different approaches at different times. While building the subtree of any node, all of the properties are maintained in a HashMap, along with a BitSet of specified properties. When the subtree construction is complete, the

Re: [PATCH] abandoning code-generated Property.Maker

2004-01-17 Thread Finn Bock
On bugzilla, Glen wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker Please give me a couple of days to comment--say 48 hours. My initial thoughts are I like what I see, esp. since appeared to you appeared to unnest the

Re: Comments on new property maker implementation

2004-01-18 Thread Finn Bock
[Glen Mazza] I've looked at your changes--I like them, and I'm thankful to have someone on our team to be able to redesign the properties as you have. Getting rid of the 250 autogenerated or so classes will be a welcome improvement. But the biggest improvement is IMHO the easy ability to create

Re: Comments on new property maker implementation

2004-01-19 Thread Finn Bock
[Finn Bock] You should perhaps also be aware that the values in a static array gets assigned to the array one element at a time. So static int[] a = { 101,102,103,104,105,106,107,108 }; becomes in bytecodes: Method static {} 0 bipush 8 2 newarray int 4 dup 5 iconst_0 [Glen Mazza

Re: Comments on new property maker implementation

2004-01-19 Thread Finn Bock
You should perhaps also be aware that the values in a static array gets assigned to the array one element at a time. So [J.Pietschmann] That's an unpleasant surprise. I was always under the impression statically initialized data was stored along with the string constants, like in C. This means a

Re: Properties question ( again? )

2004-01-19 Thread Finn Bock
[J.Pietschmann] I thought porpertyList had been retired in HEAD? PropertyListBuilder was recently removed from HEAD. [Andreas L. Delmelle] How should I see this? Is one of the two superfluous? Do they complement each other? Shouldn't the latter be rewritten as : this.BackgroundColor =

Newbie committer questions.

2004-01-20 Thread Finn Bock
Hi, I've received my account information and everything appears to work fine. In the guides for setting up CVS there are several ways to set up tunneling http://jakarta.apache.org/site/cvsonwin32.html but instead I used the :ext: protocol and set CVS_RSH=ssh with cygwin, just like I do

Re: Comments on new property maker implementation

2004-01-20 Thread Finn Bock
Finn Bock wrote: I would guess that doing ~6 string compares to navigate the binary tree (with 148 color keywords) is slower than one string hash, ~1.2 int compares and one string compare. But I haven't measured it, so you might be well be right. Many keyword sets for other properties

Re: Newbie committer questions.

2004-01-21 Thread Finn Bock
but instead I used the :ext: protocol and set CVS_RSH=ssh with cygwin, just like I do for sourceforge. Would I get any benefit from using ssh tunneling? [Jeremias Maerki] You don't have to establish the SSH connection everytime you do a CVS operation. It's speedier. Thanks, perhaps I'll give it

Unnesting properties and makers.

2004-01-22 Thread Finn Bock
Hi, After updating from CVS, it is most likely necessary to do an ant clean to get rid of the old generated maker classes, before building. I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore. I've found an argument for unnesting

Re: Unnesting properties and makers.

2004-01-22 Thread Finn Bock
I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore. [J.Pietschmann] I think you could leave the file there for now. Ok. It should be sufficient to inactivate the related task in the buildfile (for example putting it in an XML

Re: Compiling HEAD

2004-01-23 Thread Finn Bock
[Peter B. West] Is HEAD supposed to be compiling? Yes. I can compile it just fine from a fresh checkout. I'm getting errors starting at datatypes/ColorType.java. Which errors? Have you tried to do a ant clean first? regards, finn

Re: Unnesting properties and makers.

2004-01-23 Thread Finn Bock
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: [Glen Mazza] Could you explain why we have the datatypes instances to begin

Suspicious override in RtfListStyleNumber.

2004-01-24 Thread Finn Bock
Hi, While I was trying to fix some warnings from 'javadoc' about missing @see method references I discovered a suspicious construct in org.apache.fop.render.rtf.rtflib.rtfdoc.RtfListStyleNumber where the signature of the writeListPrefix(RtfList) method is different from the signature

Re: Comments on the changes to the property subsystem

2004-01-25 Thread Finn Bock
[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? 1. If I see correctly, PropertySets is not yet used.

Re: Unnesting properties and makers.

2004-01-26 Thread Finn Bock
--- 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

Re: Unnesting properties and makers.

2004-01-26 Thread Finn Bock
[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

Re: Unnesting properties and makers.

2004-01-26 Thread Finn Bock
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]

Re: Unnesting properties and makers.

2004-01-26 Thread Finn Bock
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]

Re: Unnesting properties and makers.

2004-01-26 Thread Finn Bock
[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

Re: Unnesting properties and makers.

2004-01-26 Thread Finn Bock
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)

Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-02-01 Thread Finn Bock
[Glen Mazza] Another option, Finn, is to move all the Property subclasses to fo.properties (even if they're alongside the makers, nested or unnested), after thinking about it, I think that will be a little bit clearer than having them in the datatype package. Comments? I like it. How does this

Percentages

2004-02-08 Thread Finn Bock
Hi, I just uploaded a patch which add support for percentages and calculations on percentages to bugzilla. I don't think that the patch is quite right in its attempt to find the correct base length to combine with the percentage. Some of my confusion comes from the fact that I can't tell the

Re: Percentages

2004-02-09 Thread Finn Bock
[Simon Pepping] Quite a piece of work. I will try to understand it. A small correction: margin-[top,bottom]: width of containing block, except for page context where it ^ height (I suppose). Well, not according to the spec:

Re: cvs commit: fop.bat

2004-02-11 Thread Finn Bock
[EMAIL PROTECTED] wrote: Index: fop.bat === -java -cp %LOCALCLASSPATH% org.apache.fop.apps.Fop %1 %2 %3 %4 %5 %6 %7 %8 +rem 'shift' removes %0 (i.e., the fop.bat filename) +shift +java -cp %LOCALCLASSPATH%

Re: PMC representation

2004-02-12 Thread Finn Bock
[Peter B. West] I have no problem with your continuing. If we need a formal vote, Jeremias to remain as one of our PMC representatives: +1 +1 for Jeremias regards, finn

Re: JUnit test failure

2004-02-12 Thread Finn Bock
[J.Pietschmann] Hi all, I get a nice Junit failure: Testcase: testFO2PDFWithDOM took 0.23 sec Caused an ERROR loader constraints violated when linking org/w3c/dom/Node class java.lang.LinkageError: loader constraints violated when linking This seems to have something to do mixing Jars form

[PATCH] Support for percentages and table-units

2004-02-15 Thread Finn Bock
[Simon Pepping] Finn, I see you also solved another problem, viz. that fo:layout-master-set did not return a proper IPD. Correct. There are, I'm certain, many more cases where the layout managers does not yet set all the dimensions needed to resolve all the different percentages. However, I

Re: [PATCH] Support for percentages and table-units

2004-02-17 Thread Finn Bock
Somehow, in our current design, the information must be stored in an object that exists: [J.Pietschmann] IIRC that's what the layout context was meant for. Perhaps, but I doubt it. If they was change to always get a reference to the parent layout context when they are created, and if they had a

Re: [PATCH] Support for percentages and table-units

2004-02-17 Thread Finn Bock
[Simon Pepping] If in the re-use the layout would not change, the area tree could be reused. OTOH, if the layout would change, e.g. because another renderer would use a font with a different font metric, the layout information in the FO tree cannot be reused. The layout dimension that is stored

Re: [PATCH] Support for percentages and table-units

2004-02-17 Thread Finn Bock
Perhaps, but I doubt it. If they was change to always get a reference to the parent layout context when they are created, and if they had a reference to the FObj, and if they was made available to the property subsystem, then they could properly be used for it. [J.Pietschmann] The layout

Re: [PATCH] Support for percentages and table-units

2004-02-18 Thread Finn Bock
[J.Pietschmann] The layout context has the actual IPD MinOptMax. There is no inherent reason it should have a link to a parent context or the property subsystem, it's only necessary to have a method to resolve a property expression given a set of MinOptMax for the various traits which can be used

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

2004-02-19 Thread Finn Bock
[Simon Pepping] I like the patch and the way RelativeNumericProperty holds and evaluates an expression tree (except my different preference for storing layout information, as discussed). This is really nice and works well: v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt) I found a few things that

Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Finn Bock
[me] If an expression reference another expression in a parent fo, the parent fo expression must be evaluated against the LayoutContext that was in effect for the parent fo and *not* against the child fo LayoutContext. fo:block id=a border-start-width=10% fo:block id=b

Re: [PATCH] Support for percentages and table-units

2004-02-20 Thread Finn Bock
If it is evaluated already where would the evaluated value be stored? [J.Pietschmann] The layout context for the child LM could be an appropriate place. The resolved property values of the parents should be stored in the layout context? I must be missing something here! And then the value

Re: [PATCH] Support for percentages and table-units

2004-02-21 Thread Finn Bock
If an expression reference another expression in a parent fo, the parent fo expression must be evaluated against the LayoutContext that was in effect for the parent fo and *not* against the child fo LayoutContext. fo:block id=a border-start-width=10% fo:block id=b border-start-width=inherit

Re: [PATCH] Support for percentages and table-units

2004-02-21 Thread Finn Bock
[Peter B. West] Finn, When I apply your most recent patch (10366) against a cvs updated HEAD tree and attempt to compile, I get the following: [javac] /usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: After applying the patch (10366), the

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

2004-02-21 Thread Finn Bock
[Simon Pepping] I like the patch and the way RelativeNumericProperty holds and evaluates an expression tree (except my different preference for storing layout information, as discussed). This is really nice and works well: v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt) [Peter B. West] Can

Re: [PATCH] Support for percentages and table-units

2004-02-24 Thread Finn Bock
[Finn Bock] I don't understand how you propose to solve any of this, but I hope it would be Ok to commit the straight forward solution I propose. [J.Pietschmann] Whatever works. I just want to note that given the almost one- to-one correspondence between FOs and LMs both in classes

Re: [VOTE] Clay Leeds for Committer

2004-02-29 Thread Finn Bock
[Glen] Waxing chutzpaic, I'd like us to try again to make Clay a committer on this project. +1 regards, finn

Re: [VOTE] Simon Pepping for Committer

2004-04-02 Thread Finn Bock
Glen Mazza wrote: I'd like us to go ahead and make Simon Pepping our newest FOP team member. He has provided steady ML help and numerous patch contributions for the past few months, and with the many layout patches that have been coming in recently, we could certainly use his continued help on

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-05 Thread Finn Bock
Glen Mazza wrote: Team, While I'm implementing the validateChildNode() methods, I would also like to work on removing the AddLMVisitor visitor pattern[1], and revert to our previous method of having the FO's themselves setup the LayoutManagers via addLayoutManager(). (See here [2][3][4] for

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-06 Thread Finn Bock
Glen Mazza wrote: I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. Right now I just have to replace AddLMVisitor (and the XXXLayoutManager classes). As far as I understand your proposal, I would have to

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-06 Thread Finn Bock
[Glen Mazza] I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. [Glen Mazza] Layout subsystems are much rarer than people think, so not that much a concern IMO. Keyword here is somewhat more difficult--it's

Re: [Bug 29124] - New line breaking algorithm

2004-08-12 Thread Finn Bock
Simon Pepping wrote: TextInfo derives that value from the value of the word-spacing property. That must be an error in the property handling by FOP. Yes. I'll commit a fix for it tomorrow. In FOPropertyMapping 0pt is used as the default value. Apparently normal should be the default value. I am

Re: [Bug 29124] - New line breaking algorithm

2004-08-13 Thread Finn Bock
[Luca Furini] The point is that the XSL recommendation states that the default word-spacing value is normal, meaning The normal inter-word space, as defined by the current font and/or the UserAgent, not zero. At the moment, the SpaceVal variable in the TextInfo object used by the TLM has

validateChildNode prevents extensions.

2004-08-27 Thread Finn Bock
Glen I think that the new validateChildNode() methods are too strict in response to extension elements. My guess is that the validation should only occur when one fo namespace element is added to another fo element. For instance, Block.validateChildNode() doesn't allow any of my extension

Re: validateChildNode prevents extensions.

2004-08-29 Thread Finn Bock
Extension writers has to create a subclass of AbstractLayoutManager (I just use a LeafNodeLayoutManager) and an subclass of Area. But that are normal operations since there are subclasses of those for each element type. I must also add code to the renderer to handle my area, but that is

Re: validateChildNode prevents extensions.

2004-08-29 Thread Finn Bock
I don't want to change any FOP code! And if I have to change any FOP sources to add an extension, then FOP doesn't support extension with the meaning of extension as I understand it. [Glen] From what I understand a program may not change its own source code while it is running so we may not have

Re: validateChildNode prevents extensions.

2004-08-31 Thread Finn Bock
[Glen] Oh, when I meant alter the system I also meant adding classes, using different classes, etc., i.e., some things need to be done beforehand to accomodate a new element. Come on! That leaves alter the system without any meaning. Recompiling modified sources into a new fop.jar would IMO mean

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-07 Thread Finn Bock
[Jeremias Maerki] Question to everyone: We currently don't have a multi-threaded design like Peter West's approach. Can anyone think of a reason that all the FO-building and layouting process for one processing run may run within more than one thread? I don't think threre is one if the SAX event

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-07 Thread Finn Bock
My preference would be to explicit pass the shared data (in this case the FOEventHandler) to the classes that needs it. If the recursion Glen discovered is deemed too slow, then store the FOEventHandler in an instance field for each FONode. [Jeremias] My preference, too. But having too much in

Logging of exception.

2004-09-08 Thread Finn Bock
Hi, I didn't follow the discussion in the spring about command line -d and commons-logging so I'm likely missing some important pieces, but I'm a bit confused about the result. If I attempt to render a fatally corrupt input fo file like: fo:block/ , I get the expected SAXParseException

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FOTreeBuilder.java

2004-09-09 Thread Finn Bock
[Glen] I think fox: should also be validated. It's, by definition, part of FOP core, and can't be added/adjusted to by anyone but us. Yes. I agree. regards, finn

Re: [proposal] How to do logging from the command line

2004-09-10 Thread Finn Bock
[Jeremias] Hi Finn, I took a look at it and I must say that I'm a bit confused, too. Anyway, I have a proposal to make. I would expect a command-line application to work like any other C-program such as grep, svn, ls or whatever. That means you don't get any [INFO] before each line, but you can

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-12 Thread Finn Bock
A (farfetched) argument against ThreadLocals would be that they prevent one FOP processing run to occur recursively during another independent processing run. Like an extension element that itself will attempt to process another fo document. [Glen] I think that restriction is implicit in the

Re: [VOTE] Luca Furini for Committer

2004-09-15 Thread Finn Bock
[Simon Pepping] I propose that we make Luca Furini a member of the FOP team. Here is my +1 vote. +1 regards, finn

Loading of extension element mappings.

2004-09-23 Thread Finn Bock
Hi Team, I think the API for adding additional element mappings to the FOUserAgent is bound to cause problems when fop is deployed in a multi classloader environment. Using tomcat as an example, an extension mapping deployed in a webapp can not be found if a well meaning administrator has

Re: [GUMP@brutus]: Project xml-fop (in module xml-fop) failed

2004-10-12 Thread Finn Bock
[Jeremias] If switched the junit tasks to write to System.out instead of to a file. Hopefully, we will get more usable output this way. I don't know if we can get Gump's full output somewhere so we could check the test reports. BTW, I have no errors locally. I get an error: junit: [echo]

Performance improvement in property consumption.

2004-10-13 Thread Finn Bock
Hi Team, I've put together another largish patch that changes the way properties and used by the FO objects, the layout managers and the FOEventHandler subclasses. http://issues.apache.org/bugzilla/show_bug.cgi?id=31699 The performance increase is 42% while at the same time using %27 less

Re: Performance improvement in property consumption.

2004-10-13 Thread Finn Bock
[Glen] All fo elements are required to extract all the properties that they need and to store the values as instance fields in the fo element. I love the performance boost you're recording but have a philosophical issue of an fo object needing a property--it is really an issue of the

Re: Performance improvement in property consumption.

2004-10-14 Thread Finn Bock
[Glen] So if we did this at the FO level, in effect, we'd have to (1) store an instance variable of every valid property for each FO, given that we wouldn't know whether the FOEventHandler's needs it beforehand, and [me] Yes. Which is massively more efficient than storing the exact same

Re: Performance improvement in property consumption.

2004-10-14 Thread Finn Bock
Keep in mind that there is 2 different sets of properties: - The set of specified properties. - The relevant properties (as listed in the spec under each element). The existing PropertyList stores the specified properties in the super HashMap and has an additional cache which stores all

Re: Performance improvement in property consumption.

2004-10-14 Thread Finn Bock
In my proposal the specified and the cached properties are still stored in the property list but only the relevant properties are retained in the fo object. [Andreas] Yes, and IIJC, at the same time, you're eliminating the need for downstream property queries having to be performed through the

Re: [Fwd: Re: Performance improvement in property consumption.]

2004-10-15 Thread Finn Bock
Why is it more efficient (I know it is, given your metrics, but want to know why)--aren't you just moving the values already stored in the PropertyList into separate fields in the FO objects? Yes, you're releasing the PropertyList's memory, but the elements that the PropertyList previously stored

  1   2   >