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 . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

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

Well done--I particularly liked the Ant instructions you added. Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > 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

DO NOT REPLY [Bug 25474] - Test for table-column element in PPColWidthFunction always fail.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-fop/src/java/org/apache/fop/fo/expr PPColWidthFunction.java

gmazza 2003/12/13 17:56:09 Modified:src/java/org/apache/fop/fo/expr PPColWidthFunction.java Log: Bug 25474--incorrect element name (table-column instead of fo:table-column) given in code. Patch by Finn Bock (bckfnn at worldonline dot dk) Revision ChangesPath 1.3

cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java PropertyList.java PropertyListBuilder.java

gmazza 2003/12/13 17:40:50 Modified:src/java/org/apache/fop/fo FObj.java PropertyList.java Removed: src/java/org/apache/fop/fo PropertyListBuilder.java Log: Consolidated PropertyListBuilder and PropertyList. Revision ChangesPath 1.21 +10 -28xml-fop/src/jav

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

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. Peter, please test build.sh on Unix. I hope I got the whole thing right. Jeremias Maerki

cvs commit: xml-fop/lib/bin antRun

jeremias2003/12/13 15:24:33 Removed: lib ant.LICENSE.txt ant.jar lib/bin antRun Log: Remove embedded Ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTE

cvs commit: xml-fop/lib readme

jeremias2003/12/13 15:24:13 Removed: lib readme Log: Remove out-of-date file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop build.sh

jeremias2003/12/13 15:23:43 Modified:.build.sh Log: Don't use embedded Ant. An Ant installation is now required. (tested in Cygwin, please test on Unix) Revision ChangesPath 1.24 +20 -30xml-fop/build.sh Index: build.sh

cvs commit: xml-fop build.bat

jeremias2003/12/13 15:23:03 Modified:.build.bat Log: Don't use embedded Ant. An Ant installation is now required. Revision ChangesPath 1.21 +24 -25xml-fop/build.bat Index: build.bat ==

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

J.Pietschmann wrote: > If we are at it, I'd vote for dumping generating the property > classes and check the java files into CVS. +1. I have noted Finn's and Glen's subsequent objections, and Joerg's subsequent comments. I agree that the general need for that level of flexibility has passed, and

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

Peter B. West wrote: > > It would be really nice to have a getLeaderLength() > > which returns a MinOptMax. this means the getLeaderLength() > > has: > > - resolve percentages and functions > > - deal with the leader-length shorthand setting before this > > - deal with inheritance (n/a here, fo

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

Glen Mazza wrote: > Thanks, Finn and John Austin, for your efforts here. Yes, and Peter, too. > 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 Prop

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

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 commo

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

Glen Mazza wrote: -1. I'd like to hold off on this, at least until I can gain a better understanding of the autogenerated code. I may still to the same conclusion as the other committers, but Finn's endorsement of the XSLT--as well as the long work of those like Keiron who have worked with the XS

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

I haven't looked at the XSLT code but I have a question in my mind that I need to answer about it. I wonder what it is that is being generated and what were the design alternatives to the codegen implementation. One question that popped in to my head was: Is there 'missing polymorphism' here ?

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

-1. I'd like to hold off on this, at least until I can gain a better understanding of the autogenerated code. I may still to the same conclusion as the other committers, but Finn's endorsement of the XSLT--as well as the long work of those like Keiron who have worked with the XSLT files--suggests

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

Finn Bock wrote: 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. If its commo

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

+1 to that, but please don't dump the original XML files (foproperties.xml etc.) because they could come handy later. Besides that, I can't contribute much to this discussion, but I am confident that you guys find a good solution. The "integer idea" sounds reasonable to me and I'm particularly gla

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

[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 com

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

[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 li

Re: Performance improvements.

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 it

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 . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

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 . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu