Re: Why use XML configuration files?
Roland wrote: Hello, I noticed that the apache project uses mostly XML files for configuration. Personally I prefer using .properties files because then I don't have the overhead of parsing the file each time. So what's the advantage of using XML files? They are hierarchical, can easily be transformed and published via XSLT and in some build systems used with xpath queries. Thanks for any answers... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation cocoon.diff forrest.diff
keiron 2002/12/05 01:30:16
Modified:src/documentation cocoon.diff forrest.diff
Log:
updated to latest cvs
Revision ChangesPath
1.3 +18 -19xml-fop/src/documentation/cocoon.diff
Index: cocoon.diff
===
RCS file: /home/cvs/xml-fop/src/documentation/cocoon.diff,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- cocoon.diff 20 Nov 2002 09:24:07 - 1.2
+++ cocoon.diff 5 Dec 2002 09:30:16 - 1.3
@@ -1,11 +1,11 @@
Index: src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java
===
RCS file:
/home/cvspublic/xml-cocoon2/src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java,v
-retrieving revision 1.3
-diff -u -r1.3 FOPSerializer.java
src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java 23 Sep
2002 03:30:44 - 1.3
-+++ src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java 20 Nov
2002 07:53:48 -
-@@ -62,18 +62,28 @@
+retrieving revision 1.4
+diff -u -r1.4 FOPSerializer.java
+--- src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java 21 Nov
2002 18:18:48 - 1.4
src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java 5 Dec
2002 09:21:13 -
+@@ -63,18 +63,28 @@
import org.apache.cocoon.components.url.URLFactory;
import org.apache.cocoon.util.ClassUtils;
import org.apache.cocoon.environment.URLFactorySourceResolver;
@@ -38,7 +38,7 @@
import java.net.MalformedURLException;
/**
-@@ -83,7 +93,7 @@
+@@ -84,7 +94,7 @@
*/
public class FOPSerializer
extends AbstractSerializer
@@ -47,7 +47,7 @@
/**
* The Renderer Factory to use
-@@ -96,6 +106,11 @@
+@@ -97,6 +107,11 @@
protected Driver driver;
/**
@@ -59,7 +59,7 @@
* The current codeRenderer/code.
*/
protected Renderer renderer;
-@@ -144,24 +159,6 @@
+@@ -145,24 +160,6 @@
public void configure(Configuration conf) throws ConfigurationException {
this.logger = getLogger().getChildLogger(fop);
@@ -84,7 +84,7 @@
this.setContentLength =
conf.getChild(set-content-length).getValueAsBoolean(true);
-@@ -179,28 +176,6 @@
+@@ -180,28 +177,6 @@
// New syntax: Element user-config contains URL
configUrl = conf.getChild(user-config).getValue(null);
}
@@ -113,7 +113,7 @@
// Get the mime type.
this.mimetype = conf.getAttribute(mime-type);
-@@ -232,6 +207,22 @@
+@@ -233,6 +208,22 @@
+ no renderer was specified in the sitemap configuration.
);
}
@@ -136,7 +136,7 @@
}
/**
-@@ -241,27 +232,40 @@
+@@ -242,27 +233,39 @@
return mimetype;
}
@@ -152,9 +152,9 @@
+ccf = new
org.apache.cocoon.components.source.CocoonSourceFactory(null, manager);
+ccf.enableLogging(logger);
+source = ccf.getSource(env, / + uri);
-+getLogger().error(Loading image from +
source.getSystemId());
++getLogger().debug(Loading image from +
source.getSystemId());
+InputStream is = source.getInputStream();
-+getLogger().error(input stream: + is + : +
is.available());
++getLogger().debug(input stream: + is + : +
is.available());
+return is;
+} catch (Exception e) {
+getLogger().error(Cannot load source, e);
@@ -166,7 +166,6 @@
+//userAgent.setBaseURL(source.getSystemId());
+
+driver.setUserAgent(userAgent);
-+
+}
+
/**
@@ -186,14 +185,14 @@
-if (getLogger().isWarnEnabled()) {
-getLogger().warn(Cannot load class + this.rendererName, e);
-}
--throw new RuntimeException(Cannot load class +
this.rendererName + ( + e + ));
+-throw new CascadingRuntimeException(Cannot load class +
this.rendererName, e);
-}
-}
-this.driver.setRenderer(this.renderer);
this.driver.setOutputStream(out);
setContentHandler(this.driver.getContentHandler());
}
-@@ -295,8 +299,7 @@
+@@ -296,8 +299,7 @@
*/
public void recycle() {
super.recycle();
@@ -203,7 +202,7 @@
}
/**
-@@ -306,3 +309,4 @@
+@@ -307,3 +309,4 @@
return this.setContentLength;
}
}
@@ -214,7 +213,7 @@
retrieving revision 1.24
diff -u -r1.24 AbstractProcessingPipeline.java
---
cvs commit: xml-fop/src/org/apache/fop/image GifImage.java
keiron 2002/12/05 02:29:12
Modified:src/org/apache/fop/image GifImage.java
Log:
use a dummy url connection to enable loading of gif image
Revision ChangesPath
1.7 +58 -10xml-fop/src/org/apache/fop/image/GifImage.java
Index: GifImage.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/GifImage.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- GifImage.java 14 Nov 2002 15:19:41 - 1.6
+++ GifImage.java 5 Dec 2002 10:29:12 - 1.7
@@ -12,6 +12,9 @@
import java.awt.image.ColorModel;
import java.awt.image.IndexColorModel;
import java.awt.color.ColorSpace;
+import java.io.InputStream;
+import java.io.IOException;
+import java.net.URLConnection;
// FOP
import org.apache.fop.pdf.PDFColor;
@@ -26,26 +29,36 @@
* @see FopImage
*/
public class GifImage extends AbstractFopImage {
-public GifImage(FopImage.ImageInfo imgReader) {
-super(imgReader);
+/**
+ * Create a new gif image.
+ *
+ * @param imgInfo the image info for this gif image
+ */
+public GifImage(FopImage.ImageInfo imgInfo) {
+super(imgInfo);
}
+/**
+ * Load the bitmap for this gif image.
+ * This loads the data and creates a bitmap byte array
+ * of the image data.
+ * To decode the image a dummy URLConnection is used that
+ * will do the conversion.
+ *
+ * @param ua the user agent for loading
+ */
protected boolean loadBitmap(FOUserAgent ua) {
int[] tmpMap = null;
-
try {
-ImageProducer ip = null;
-// todo: how to load gif image from stream
-//ip = (ImageProducer) inputStream.getContent();
-inputStream.close();
-inputStream = null;
+URLConnection con = new DummyConnection(inputStream);
+
+ImageProducer ip = (ImageProducer) con.getContent();
if (ip == null) {
return false;
}
FopImageConsumer consumer = new FopImageConsumer(ip);
ip.startProduction(consumer);
-
//Load the image into memory
while (!consumer.isImageReady()) {
Thread.sleep(500);
@@ -62,6 +75,9 @@
return false;
}
+inputStream.close();
+inputStream = null;
+
ColorModel cm = consumer.getColorModel();
this.bitsPerPixel = 8;
// this.bitsPerPixel = cm.getPixelSize();
@@ -144,5 +160,37 @@
return true;
}
+/**
+ * A dummy url connection for a gif image in an input stream.
+ */
+protected static class DummyConnection extends URLConnection {
+InputStream inputStream;
+DummyConnection(InputStream is) {
+super(null);
+inputStream = is;
+}
+
+public InputStream getInputStream() throws IOException {
+return inputStream;
+}
+
+public void connect() throws IOException {
+// do nothing
+}
+
+public String getContentType() {
+return image/gif;
+}
+
+public int getContentLength() {
+try {
+return inputStream.available();
+} catch (IOException e) {
+
+}
+return -1;
+}
+
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why use XML configuration files?
Roland wrote: I noticed that the apache project uses mostly XML files for configuration. Personally I prefer using .properties files because then I don't have the overhead of parsing the file each time. So what's the advantage of using XML files? Properties are flat and non unicode-aware, that's bad enough. xml is hierarchical, unicode-friendly, platform independent and widely supported, that's good enough -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Karen Lease wrote: Peter, ... ... I will make a few comments on the redesign issue. I agree with Arved that we certainly have some large problems to face. As he points out, the mainstream redesign suffers from not being understood and therefore from a lack of active contributors. ... Insofar as I was quite involved in the initial idea and in some of the initial coding, I certainly helped chart this course, and there was quite a lot of discussion on the list concerning these ideas. I was aware of that, and I apologise if I have given the impression that I was not. Unfortunately I've been unable, because of work pressure, to contribute anything useful to the rewrite since early summer. However, I've tried to at least keep an eye on what was going on. What I see is that Keiron has been carrying on almost alone with the rewrite which we had started together, despite quite a lot of efforts to get more people (Joerg notably) involved in it. It's clear that one person on such a large job is not enough, even if the person has as much energy and talent as Keiron. And even if I were still involved, two people is still not enough. I did make some efforts to describe the general idea early this year, and Keiron wrote quite a lot of things as well: the whole understanding series and some design notes. But if people are not able to get over the entry barrier, than perhaps the idea or the way it is implemented is just too complex. Or perhaps we haven't written the right kind of documents. This may be the nub of the documentation problem. I fall into a similar trap very often. From within your own understanding it is almost impossible to get back to the pristine mind-set of anyone approaching the problem cold. I have never seen this problem dealt with very successfully anywhere. However, I think there is another factor contributing to the lack of general involvement in the rewrite streams, either the main or the alt-design. This is that a large number of people, and I assume that includes many of the committers, are actually using FOP on a day-to-day basis to do real work. When one is in that state, it is much easier to justify working on fixing critical (or even just plain annoying) bugs in the 0.20.x series than to find time to bring forward a developer release which is not yet capable of actually composing most documents. I know we already had this discussion some months ago and it was more or less decided to try to put out 0.20.5 and to stop development on the maintenance branch. I don't know if this is really possible; I for one am now using FOP in production and need some work done which will not be done in 0.20.5 (assuming we push it out the door fairly soon.) Until we get over this hurdle, neither Main nor Alt-design is going to be able to get far enough along to prove that it can do a better job at layout than current FOP. I still basically believe in the rewrite, and I don't know enough about Alt-design to judge its merits. I think we _do_ need to focus on the essential: implementing an FO processor. I personally don't think building the FO tree or even property handling is central to our problems today. Neither is perfect, but both are functional. I agree that implementing an FO processor is the essential thing. Alt.design started as a sidetrack for me to 1) implement pull-processing (although I didn't call it that) for the FO tree bulding, 2) to see whether properties could have a more compact resolution, and 3) to look at a galley-based method of implementing the layout engine. Properties just sucked me dry, as you would understand. Although it is not yet complete, if the FO tree work were found to be useful, it could be bolted onto the existing design without an outrageous amount of work. In any case, I am now at the point of seriously considering where to put my effort in the layout. If you can convince me that it's going to work I will join you. There is an implication in what you are saying that you do have the direction forward for the FO processor internalised, so to speak, and that a complete FO processor is, as Christian says, just a matter of time. I, and I suspect Arved, wonder why that is not clear to everyone. You have a great track record in FOP over a long period, and if you insist that the redesign is moving towards completion, I would be inclined to believe you, but I do need to be shown how. Arved also has a great track record over many years in FOP, and Arved seems to be skeptical. In any case, I would like to be able to make useful suggestions concerning the redesign. I have many times in the past expressed the genuine hope for the success of FOP by whatever path, and I had never, until recently, even suggested that anyone commit to alt.design over the HEAD redesign. I cannot, however, commit to a design that I either do not understand, or do not have any confidence in. Who can? In order for the software
Re: bugzilla shake-up is over
On Wed, 2002-12-04 at 19:08, Oleg Tkachenko wrote: Hello there! Well, bugzilla shake-up is over, sorry if I closed something not-to-be-closed or leave something-to-be-closed, but anyway I believe we can say bugzilla is cleaned up now. Now it's 111 entries in there (it was 188 IIRC): Blockers: 3 Criticals: 6 Majors: 17 Normals: 67 Minors:6 Enhancements: 12 There are 4 patches among them. Not bad. Thanks a lot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Responses below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 5:27 PM To: fop-dev Subject: Redesign issues This is the question that everyone has to answer. Blind faith that that the problem can be solved by simply hurling onself at it is not enough. I'm not saying that Keiron and Karen are in that situation, but I suspect that others are. An elegant and comprehensive plan of attack, including a design approach that can confidently be expected to crack the toughest problems, may exist in their imaginations, but it needs to be made manifest before any sort of team attack can be made on the problems. This is something I'd really like to see hashed out better. We're winding down on the maintenance brach. I've read a majority of the source in HEAD other than the renderers (which I don't feel qualified or interested in, anyway), and I understand the ideas in there, but I don't see the line of attack we want to take with this. I, personally, would like to see some objectives and plans laid out that I and others can follow, especially with respect to the layout mechanisms. I'm doing my best to be involved and follow the lead of the committers here, but the lead's not clear. With respect to the layout system, Keiron has explained a few of the smaller aspects of what should happen when he's got the whole thing together, and I would like to help in making that happen, but I really feel that I can't until I see the plan. As a developer, I'm following the lead of my committers. My personal problems aside, we're approaching a maintenance freeze, right? Shouldn't that mean it's time to figure out what our next step is going to be in a very clear way and keep hashing this out until we've got a list of tasks to complete? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
On Thu, 2002-12-05 at 13:01, Peter B. West wrote: There is an implication in what you are saying that you do have the direction forward for the FO processor internalised, so to speak, and that a complete FO processor is, as Christian says, just a matter of time. I, and I suspect Arved, wonder why that is not clear to everyone. You have a great track record in FOP over a long period, and if you insist that the redesign is moving towards completion, I would be inclined to believe you, but I do need to be shown how. Arved also has a great track record over many years in FOP, and Arved seems to be skeptical. Please define redesign. The following things are at least better than anywhere else: area tree, image handling, pdf lib, svg, renderer. Fo tree is better than the maintanence branch. If you are referring to the layout then I can't say that it is anywhere near completion, but in general it is currently better than the maintanence branch. (lack of a number of features and missing words aside) It seems to me that a lot of the arguments are of this type: http://www.intrepidsoftware.com/fallacy/straw.htm As far as I am concerned it is largely irrelevant whether the particular layout design is 100% correct. Yes it is extermely important and will be best tackled by breaking it down into smaller problems. But so far I have only heard arguments against two methods in the layout managers, getting breaks and reset. Sure it probably would be helpful to design a layout algorithm isolated from all the other stuff and that is something that someone could pursue. Believe me, I can find plenty of other things to do that have no relation to the layout. Still, from my perspective it is a high priority to get it to a level similar to the maintanence branch, this will make fixing bugs, responding to users, integration with other projects documentation etc. a lot easier. Then to move forward from there. In any case, I would like to be able to make useful suggestions concerning the redesign. I have many times in the past expressed the genuine hope for the success of FOP by whatever path, and I had never, until recently, even suggested that anyone commit to alt.design over the HEAD redesign. I cannot, however, commit to a design that I either do not understand, or do not have any confidence in. Who can? If all you care about is a perfect layout then that is reasonable, then reduce the problem/difference to the layout. Most users care more about lots of other issues. Catering for these users will help us IMHO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: bug #13586
Oleg Tkachenko wrote: Hello there! What do you think about http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13586? Stefan asks us to use something like float currentLetterSpacing = (float) 9.99; instead of float currentLetterSpacing = Float.NaN in PDFRenderer.java due to jre-1.3.1 for linux-alpha bug. For me it looks too patchy. I suggest to resolve the bug as WONTFIX as I would use Float.MAX_VALUE instead of (float) 9.99 Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
J.Pietschmann wrote:
[..]
web.xml: keep it with the *.java.
I would prefer something like src/conf/web.xml
servlet.jar: provide a property for the location, defaulting
to lib/servlet.jar. Conditionalize the servlet compilation
on availability of ${servlet.jar}. Users can either copy a
servlet.jar to the lib directory, or use a
-Dservlet.jar=/foo/bar/servlet-2.3.jar
on the command line (or whatever the proper Ant syntax is for
defining properties for the CLI).
I had planed to remove the old docs/example/embedding and add
the contrib/servlet stuff to the distributen for the release
but if you want to change this I don't mind.
This has at least the advantage of one classpath less to take care of.
Christian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: website
Victor Mote wrote: I see that Keiron has republished the web site. Here are some comments: 1. Keiron, would it help any, now that you have gotten the basic flow going, for one of us to take the web-site publication burden from you? I know Christian is involved in doc. If he does not wish to do it, I would be happy to run that. If reasonable, I would make an effort to publish it daily. What I don't mind at all ;-) 3. I envision the Compliance document to be a replacement for the Implemented and Limitations documents. It was built from information on those two pages, as well as a complete listing of objects properties, and the information about standard compliance levels. Is there any objection to removing these documents? I'll double-check to make sure no useful This makes sense (a comment about leader seems to be missing) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
bsf.jar
Hi all, I just noticed bsf.jar in the lib directory and IIRC it was needed by xalan1. As we switched to xalan2 some time ago is it ok for everyone if I remove bsf.jar? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs for maintenance release
Jeremias Maerki wrote: How will we maintain the website after the copy? Change in trunk then copy over to maint branch each time something is changed? Or can we Yes, I'm not sure if automatic merging would work and I don't think there will be a lot of changes. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP schema
Peter B. West wrote: Victor Mote wrote: While working on an FAQ for FO dtd schema, I see that we have two schema in docs/foschema: fop4f.xsd fop4.xsd. They are similar. Does anyone know what the purpose for both is, why we have 2, or the 4 4f designations? Victor, I think that Chuck was appending a letter to each version of the schema. When he submitted fop4g.xsd, I cleaned the tabs out of fop4f.xsd, and committed that file as fop4.xsd. I then did similar clanups on fop4g.xsd, and committed that as a change to fop4.xsd. So from fop4.xsd, you can recover the latest two versions of the file. fop4f.xsd is for historical reference only, left in case there were any problems with my cleanups of fop4.xsd. At the time I let Chuck know what I had done, and asked him if he could submit a diff against that file as his next version. See http://marc.theaimsgroup.com/?l=fop-devm=103547432006815w=4 If no one objects, I would like to move this information to fop.xsd let CVS handle the revision issues. The viewcvs program allows us to append a revision number, so we could even branch tag this to keep it tied to releases. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15119] New: - fo:external-graphic and border 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=15119. 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=15119 fo:external-graphic and border properties Summary: fo:external-graphic and border properties Product: Fop Version: 0.20.4 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I want to render a graphic inside a box with the following properties : fo:external-graphic src=graph.png width=4in border-color=black border-width=thin border-style=solid/ the box is missing despite you mention that FOP is full compliant with these properties. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13586] - fop will not work on linux alpha because jre is broken (workarround included)
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=13586. 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=13586 fop will not work on linux alpha because jre is broken (workarround included) --- Additional Comments From [EMAIL PROTECTED] 2002-12-05 23:34 --- Christian suggests using Float.MAX instead of 9.99. That makes things a little tidier, and makes accidental use of the value a few orders of magnitude more unlikely. I think that it could be integrated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP schema
Victor Mote wrote: If no one objects, I would like to move this information to fop.xsd let CVS handle the revision issues. The viewcvs program allows us to append a revision number, so we could even branch tag this to keep it tied to releases. Sounds OK. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote: On Thu, 2002-12-05 at 13:01, Peter B. West wrote: There is an implication in what you are saying that you do have the direction forward for the FO processor internalised, so to speak, and that a complete FO processor is, as Christian says, just a matter of time. I, and I suspect Arved, wonder why that is not clear to everyone. You have a great track record in FOP over a long period, and if you insist that the redesign is moving towards completion, I would be inclined to believe you, but I do need to be shown how. Arved also has a great track record over many years in FOP, and Arved seems to be skeptical. Please define redesign. The following things are at least better than anywhere else: area tree, image handling, pdf lib, svg, renderer. Fo tree is better than the maintanence branch. See comments below. If you are referring to the layout then I can't say that it is anywhere near completion, but in general it is currently better than the maintanence branch. (lack of a number of features and missing words aside) It seems to me that a lot of the arguments are of this type: http://www.intrepidsoftware.com/fallacy/straw.htm As far as I am concerned it is largely irrelevant whether the particular layout design is 100% correct. Yes it is extermely important and will be best tackled by breaking it down into smaller problems. But so far I have only heard arguments against two methods in the layout managers, getting breaks and reset. Sure it probably would be helpful to design a layout algorithm isolated from all the other stuff and that is something that someone could pursue. Noted. Believe me, I can find plenty of other things to do that have no relation to the layout. Still, from my perspective it is a high priority to get it to a level similar to the maintanence branch, this will make fixing bugs, responding to users, integration with other projects documentation etc. a lot easier. Then to move forward from there. In any case, I would like to be able to make useful suggestions concerning the redesign. I have many times in the past expressed the genuine hope for the success of FOP by whatever path, and I had never, until recently, even suggested that anyone commit to alt.design over the HEAD redesign. I cannot, however, commit to a design that I either do not understand, or do not have any confidence in. Who can? If all you care about is a perfect layout then that is reasonable, then reduce the problem/difference to the layout. Most users care more about lots of other issues. Catering for these users will help us IMHO. Keiron, We seem to have achieved considerable agreement here. From what you say above, the HEAD redesign is nearing the point at which it can take over from the maint branch as the usable version of FOP. That solves one of the problems that Karen mentioned, and will integrate the efforts of those with production commitments, and those working on the New Design. You say, above: Sure it probably would be helpful to design a layout algorithm isolated from all the other stuff and that is something that someone could pursue. I'll put my hand up for this. It is my intention to scavenge as much code as possible from HEAD to implement the design. It may not come to that. If those working on HEAD adopt elements of alt.design as they see the possibilty and benefit of so doing, the incremental design approach you favour and alt.design may turn out to be synergistic. In any case, I hope to pursue these goals without feeling a pariah in the FOP development community, when my purpose is a better FOP. I hope this goal remains relevant across Sun's pending announcement. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alt-Design: Preliminary results FO tree build test
Rhett, Nerver having used it, I am not aware of its capabilities. As I don't develop in a Microsoft environment, and have no access to MS Visual C++, and I don't run in a Solaris environment, my options for trying this are limited. If anyone else want to have a look I would be interested in the results. I am particularly interested in memory usage, which, prima facie, looks good. 9 megs total memory usage for 51 pages of FO tree sounds very encouraging to me, although I have called these preliminary because I am not certain that everything that needs to be created has been created. Unfortunately, since FOP was changed to trigger layout on the end element of a page-sequence, no complete FO tree is built in the current versions. There are, however, only two page sequences in the fo file, so the simple solution may be to remove the the smaller of these for the comparisons. Peter Rhett Aultman wrote: Hmmm...maybe we could use a JVM profiler like jProf (http://starship.python.net/crew/garyp/jProf.html) for this? -Original Message- From: Oleg Tkachenko [mailto:[EMAIL PROTECTED]] Peter B. West wrote: Herewith the preliminary results of running the alt.design FO tree build against the 51 page test document supplied by Bertrand. What is included in this measurement? I presume it's fo parsing, userconfig processing and fo tree buiding? Thanks for the file Bertrand. The file yields a tree of 11044 nodes. The pull buffer is set to 64, the maximum size of the FoXMLEvent pool is 74, and the total number of FoXMLEvent objects created is 78 (next event id -1). The sytem is a 256Mb PII laptop running Sun's Java 1.4.1 under Redhat 7.3. Elapsed time from the beginning of org.apache.fop.apps.Fop main to the end of the FO tree build is 15960. The preorder scan of the tree takes that to 16176. The test is run within a 'time' command with the results 18.02s real11.71s user 0.24s system It's rather interesting to compare it with the trunk code. But I believe we need real profiler software results to make any serious conclusions. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Alt-Design: Preliminary results FO tree build test
I have a Solaris box (Sun Blade 100) here at home, but the sources should compile on Linux, I would think. I'm actually looking at integrating a jProf library into an MBean for the JBoss project, and I did all my preliminary work on my Solaris box (some of that research will be in the February issue of Java Developer's Journal, barring any catastrophes). I could run the tests over here, in theory. Maybe we should discuss the specifics of a test in private? -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Thu 12/5/2002 9:47 PM To: [EMAIL PROTECTED] Cc: Subject: Re: Alt-Design: Preliminary results FO tree build test Rhett, Nerver having used it, I am not aware of its capabilities. As I don't develop in a Microsoft environment, and have no access to MS Visual C++, and I don't run in a Solaris environment, my options for trying this are limited. If anyone else want to have a look I would be interested in the results. I am particularly interested in memory usage, which, prima facie, looks good. 9 megs total memory usage for 51 pages of FO tree sounds very encouraging to me, although I have called these preliminary because I am not certain that everything that needs to be created has been created. Unfortunately, since FOP was changed to trigger layout on the end element of a page-sequence, no complete FO tree is built in the current versions. There are, however, only two page sequences in the fo file, so the simple solution may be to remove the the smaller of these for the comparisons. Peter Rhett Aultman wrote: Hmmm...maybe we could use a JVM profiler like jProf (http://starship.python.net/crew/garyp/jProf.html) for this? -Original Message- From: Oleg Tkachenko [mailto:[EMAIL PROTECTED]] Peter B. West wrote: Herewith the preliminary results of running the alt.design FO tree build against the 51 page test document supplied by Bertrand. What is included in this measurement? I presume it's fo parsing, userconfig processing and fo tree buiding? Thanks for the file Bertrand. The file yields a tree of 11044 nodes. The pull buffer is set to 64, the maximum size of the FoXMLEvent pool is 74, and the total number of FoXMLEvent objects created is 78 (next event id -1). The sytem is a 256Mb PII laptop running Sun's Java 1.4.1 under Redhat 7.3. Elapsed time from the beginning of org.apache.fop.apps.Fop main to the end of the FO tree build is 15960. The preorder scan of the tree takes that to 16176. The test is run within a 'time' command with the results 18.02s real11.71s user 0.24s system It's rather interesting to compare it with the trunk code. But I believe we need real profiler software results to make any serious conclusions. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
