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.
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.
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
[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
[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
+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 glad
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
-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
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 ?
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
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
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
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, fortunately)
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
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
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
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]
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
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
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=25474.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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 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.
22 matches
Mail list logo
