Re: markers in redesign
Arved Sandstrom wrote: ... That means, to me, first, that we use the naming to identify qualifying areas. Two, we use "retrieve-boundary" to filter out qualifying areas. I make that distinction, because qualifying areas are defined by the naming alone. Three, we use "retrieve-position" coupled with area traits (and the traits are easy to establish) to figure out the best qualifier on the _current_ page. The thing that bugs me is, when there is no qualifying area in the "containing page" (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user preferences based on "retrieve-position" lose all relevance. In other words, there is an elaborate set of definitions based on the current page, with a hierarchy defined by "retrieve-position", but as soon as one establishes that there is no such qualifying area on the current page, than it's just the first qualifying area one can find, moving back in the document. I suppose that one way of looking at this is that retrieve-position is inherently this-page based, and that to try to extend the retrieve-position logic in a consistent way to, say, previous page, would add a layer of some complication. The easy solution is to declare that, if you blew it with the retrieve-position properties, all bets are off, and we go into emergency mode. -- 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: markers in redesign
Keiron Liddle wrote: Hi all, Is it correct that it should look for markers on the current page and if page boundary is current page then stop there. If boundary is page-sequence then keep going backwards on each page until a marker is found or reaches the start of the page-sequence and similarly for the document boundary. I'm trying to work out exactly how the markers should work. For the first starting within page and last ending I am fine with. First including carry-over seems okay. Last starting within page is a bit confusing. A statement [1] in the spec suggests that it shouldn't really find the last starting in the page but rather find the closest node to the root in the area tree that is the last starting area. Another statement [2] seems confusing but maybe this is if it is searching previous pages. So if this was in a page then block "a" would be the last starting in the page. -start-- ... ---pos1- end--- But if there is a column break in pos1 the last starting in page will become block "c" as block "a" is not starting in that part of the area tree. Keiron, I haven't looked at markers too closely, but I would tend to think that, in the first case, block c is the last-starting-within-page. Blocks a, b and c all qualify; they all have an is-first trait of "true". So which one follows all others in the area tree, *in pre-order traversal order*? Pre-order traversal gives us a, b, c. So c "follows in the area tree any other similarly constrained area. Then the column break would have no impact on the selection. It seems to me that the "hierarchy" is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. I think. Peter If this is the case then there are two possible cases when starting an area: isfirst and other. When finishing an area there are: islast, (had) isfirst and both. This will supply enough information to add only the needed markers to the area tree. These markers can then be kept for later retrieval. [1] "Every area in the hierarchy is considered preferential to, or "better" than, any area below it in the hierarchy." [2] "If there is no such area, then the last qualifying area in the containing page is better than any other area." -- 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: Markers in areas
Arved Sandstrom wrote: They are not connected concepts, Mark. I originally put in the code for lineage pairs, and also started the implementation for markers. So I can assure you that they are completely unrelated. For what it's worth, subsequent contributors have significantly improved on marker support, so I am only commenting from the viewpoint of my knowledge of the spec. I made a few comments in my reply to Joerg. I have a degree in physics, and most of a Masters in physical oceanography. I see considerable mathematical anarchy in the XSL spec, some degree of mathematical naivete, and lots of confusion. My forte is not logic, based on my background, but even a physics guy can dissect the pseudo-logic in that spec. I think plenty of other people have also separated the wheat from the chaff as far as that document is concerned...I think we are due for a rewrite, with lots of the pretentious math excised, and replaced with plain language. Arved, Hear, hear. Arved, have you told the editors this directly? If not, please do. -- 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: Markers in areas
Arved Sandstrom wrote: Joerg, you can freely get rid of that stuff. I originally introduced it when I had more faith in the spec, and thought that the authors knew what they were talking about when it came to to their math. Specifically, the lineage pairs is an abstract concept that I can see no implementation use for. In fact, I can't see any theoretical use for the idea either. Arved, I'm glad that I am not the only one who could see no purpose in the discussion of "lineage". However, I'd like your comments on a couple of aspects of lineage. The first of the two parts of the definition: A set of nodes in a tree is a lineage if: * there is a node N in the set such that all the nodes in the set are ancestors of N, and This seems a strange. Normal areas represent areas in the "normal flow of text"; that is, they become area children of the areas generated by the formatting object to which they are returned. Normal areas have a returned-by lineage of size one. I wondered about the point of all this, but in looking at the Errata, I found a series of modifications for the description of 'Areas' in the description of fo:bidi-override, fo:inline and fo:basic-link as follows: Section 6.6.2 Replace: in the "Areas:" portion "returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children" with "returns these areas, together with any normal block-areas, page-level-out-of-line areas, and reference-level-out-of-line areas returned by the children" It seesm to me that these changes create normal block areas with a lineage with size greater than one. What do you think? -- 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: Licence issues in hyphenation patterns
Jeremias Maerki wrote: On 20.02.2003 23:58:48 J.Pietschmann wrote: BTW we should track down and delete all binary distribution containing the compiled hyph file from the three GPL sources. The source distributions are not an immediate risk and can be kept. Who has access to the distro repository? Good thought! As long as we are still able to recover complete historical binary distributions. If a problem arises over a past distribution, we are far better off if we can refer to the actual distribution, even if that is no longer available for general distribution. -- 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: Long licence
Jeremias, Can we put the copyright notice at the end of the files? It's a PITA haaving it at the beginning. I'll change the FOP_0-20-0_Alt-Design files. Peter Jeremias Maerki wrote: Thanks, your help is most welcome. Yes, we have to change all three :-) codebases. On 20.02.2003 08:33:31 Oleg Tkachenko wrote: Jeremias Maerki wrote: That's it. The board has finally spoken. We need to change to long licences in our codebase. Anyone out there with free time? If not, I can do it. I can help you. Should we change both codebases? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- 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]
Offline
Going camping in the Bunya Mts. Offline until Thursday. -- 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: Another release candidate ...
Christian Geisert wrote: Ok, in a perfect world the 0.20.5 release would have happend last year and we all were working on HEAD now but in reality we're still fixing bugs (which is ok as it will take some time till the first "redesign-relase") but nevertheless we should finally finish 0.20.5. So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) Comments? +1 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: [Fwd: Percentages + absolute lengths]
Fopdevs, Sorry about the delay in getting the integration wiki going. One of the reasons was that I wanted to formulate a couple of questions to the editors about aspects of the property handling, because the issues had the potential to cause awkward modifications to the code. The one that was most awkward is precised below. Peter B. West wrote: Original Message Subject: Percentages + absolute lengths Date: Fri, 07 Feb 2003 02:21:32 +1000 From: Peter B. West <[EMAIL PROTECTED]> To: xsl-editors <[EMAIL PROTECTED]> Please clarify the editors' expectation for the resolution of an expression like "25% + 3pt" an FO where the relative value is resolved in terms of an enclosing reference area. ... My current implementation of FO tree building rejects expressions such as "25% + 3pt" on the basis that (part of) "...the expression value cannot be converted to the necessary type for the property value," (5.9.12) within the context of the building of the FO tree. This is in spite of the fact that the spec states, fatuously in my view, that, "Properties are evaluated against a property-specific context. This context provides: ... Conversions from relative numerics by type to absolute numerics within additive expressions." I am sure that I will get caned on this one by the editors. Being able to write "25% + 3pt" is too fundamental and "natural" an expression to suppress, and the spec specifically mentions the resolution of relative lengths within additive expressions, of which "25% + 3pt" is presumably an example. Unfortunately the spec also makes great play of the fact that the FO tree properties are "conceptually" refined in advance of the construction of the area tree. However, the editors have an out. Section 3. Introduction to Formatting, contains this little Catch-22: "Some of these operations (particularly evaluating expressions) depend on knowledge of the area tree. Thus refinement is not necessarily a straightforward, sequential procedure, but may involve look-ahead, back-tracking, or control-splicing with other processes in the formatter." This makes a mockery of the whole preceding "conceptual" description of the process, by making quite clear (to those who have already banged their heads against this particular wall) that the FO tree cannot be developed in isolation from the Area tree. From memory, Ken Holman recently posted a message on the exslfo list in response to a request for the formalisation of access to the FO tree. He noted that one company (which he would not name) had developed a formatter which did not generate an area tree at all. I know why. Attached is a scratch diagram from my alt.design notes about the relationship between various components if the design, and where I saw the FO tree build fitting in. At that stage I was still thinking that the FO tree could be built in isolation, but the structure I sketched can still work. The feedback loop labelled "FO completion messages" from the Area tree builder to the FO tree builder becomes busier. It feeds back information on all of the areas that it is building, so that the FO tree builder can construct the area tree context of the FOs it is building. The basic process of passing events through a buffer is reasonably efficient, as shown by the alt.design FO builder, and the model does allow for clean isolation of components. The other possibility is to make a nauseating mess of the property parsing, creating special cases for additive expressions containing percentages, and going through the expression parsing again within the area tree build when the appropriate context is available. Note that the parsing already accommodates percentages as special cases through an IndirectValue class. Integrating FO and Area tree builds in the way I am thinking about will eliminate the need for that class, as all percentages would be resolved immediately. Once it is constructed, there exists always the possibility of optimisations, including the use of some more directly realised use of co-routines, and the elimination of the area tree as a separate entity. From my current perspective, I don't see either of those as strong possibilities. I will detail these options as I get the Wiki going, but would appreciate any fedback in the meantime. 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]
[Fwd: Questions about markers]
FYI Peter Original Message Subject: Questions about markers Date: Fri, 07 Feb 2003 02:11:16 +1000 From: Peter B. West <[EMAIL PROTECTED]> To: xsl-editors <[EMAIL PROTECTED]> Background: Processing of large FO documents is both cpu and memory intensive. The volume of property information is partly responsible for the memory requirement. In order to minimise this demand, I want to be able to divide the property construction into two phases with different requirements. 1. The construction of individual branches of the FO tree. During this phase, as tree building proceeds down a particular branch towards a leaf node, the ancestor nodes of that leaf are constructed without knowledge of the requirements of descendants. Therefore, no optimisaton is possible of the set of properties which must be maintained at each ancestor node. Whether a particular specified or inherited property is required by an individual ancestor node, a full set of properties must be developed and maintained (at least conceptually) until the inheritance and functional reference requirements of the last descendant have been determined. These sets are constructed as control descends down the tree, making the set available to each child and its descendants. 2. As control retreats back up the tree, having constructed the property sets of each of its descendants, there is no further need for any but the actual properties pertaining to each individual node. This allows for considerable space (and subsequent performance) optimisations, by, e.g., reducing the applicable property set to the minimum required by the FO, and maintaining that set in an array of predetermined length, whose elements can be accessed by a mapping array, whose length and contents are predetermined. This neat and compact arrangement may be disturbed by the presence of markers. Markers do not inherit from their FO tree ancestors, but from their ancestors determined in the Area tree. The properties of retrieved marker subtrees are necessarily resolved in the context of the Area tree; the marker retrieved at a certain point is determined by the status of the Area tree construction. Given this close connection with the Area tree, I wish to have clarified the environment of expression resolution for markers, in particular as it affects inheritance and the from-nearest-specified-value() function. Questions: Is this environment conceptually akin to that which would obtain were the fo:marker subtree transposed to the position in the FO tree occupied by the fo:retrieve-marker during phase 1 of FO tree construction? In this case, all properties specified and inherited are available to "normal" inheritance and to the core functions. Is it akin to that which would obtain were the fo:marker subtree transposed to the same position in the FO tree following phase 2, as described above? In this case, only properties which were relevant to particular FOs would be retained. The point at which a property was specified would be lost if it were not relevant at the point of specification. Is it rather the environment which derives from the traits of the Area tree at the point of attachment? This case is similar to the one above, in that information about properties which had no prior point of application would be lost before the fo:marker subtree properties were resolved. 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]
[Fwd: Percentages + absolute lengths]
FYI Peter Original Message Subject: Percentages + absolute lengths Date: Fri, 07 Feb 2003 02:21:32 +1000 From: Peter B. West <[EMAIL PROTECTED]> To: xsl-editors <[EMAIL PROTECTED]> Please clarify the editors' expectation for the resolution of an expression like "25% + 3pt" an FO where the relative value is resolved in terms of an enclosing reference area. The difficulty with respect to such expressions that I have experienced in implementing FO tree building is that they force property resolution into dependency on Area tree construction. Even in the simplest cases, the evaluation of such expressions assumes the availability of page-based information, as opposed to the FO tree's flow and static-content view. I those cases where the dimensions of areas may be dependent on look-ahead layout and retries, e.g. during attempts to resolve column widths for "auto" column layout, the dependency becomes even more tortuous. The end result is that such expressions must be carried around in the constructed FO tree, and only resolved as the applicable FO's areas are generated and returned, or re-generated and returned. This greatly complicates the expression parsing which must be done early for the FO tree building to be able to proceed. While a simple percentage, e.g., "25%", suffers from the same uncertainties, it can at least be reduced to a single datum, whose resolution makes no further demands of the expression parser, which in turn simplifies the parser. My current implementation of FO tree building rejects expressions such as "25% + 3pt" on the basis that (part of) "...the expression value cannot be converted to the necessary type for the property value," (5.9.12) within the context of the building of the FO tree. This is in spite of the fact that the spec states, fatuously in my view, that, "Properties are evaluated against a property-specific context. This context provides: ... Conversions from relative numerics by type to absolute numerics within additive expressions." The context of this conversion is not property-specific as much as area-tree specific. 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: [Fwd: RenderX XEP Academic Edition available]
Oleg Tkachenko wrote: Peter B. West wrote: Should Apache, as a non-government, non-profit organization, apply for a copy of RenderX Academic to install on, say, cvs.apache.org? Hmmm, what for? For comparison. Or is RenderX available to any of us by some other means? 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: Fix for fo:leader
J.Pietschmann wrote: - I get a value of 54 for the text align occasionally. I suspect this is "inherit". Does one of the property gurus know what this means offhand? Joerg, My initial response - no, but try me with '42'. Later... In .../fo/properties/Constants.java from fop-0_20_2-maintain (not built for a while): public final static int INHERIT = 51; public final static int INSET = 52; public final static int INTEGER_PIXELS = 53; public final static int JUSTIFY = 54; 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]
[Fwd: RenderX XEP Academic Edition available]
Fopdevs, Should Apache, as a non-government, non-profit organization, apply for a copy of RenderX Academic to install on, say, cvs.apache.org? Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" --- Begin Message --- Hi, RenderX (http://www.renderx.com/) announces free of charge availability of the Academic edition of fully functional version of its XSL Formatting Objects implementation RenderX XEP (http://xep.xattic.com/) to universities, academic institutions and non-government non-profit organizations. The edition is a special version of RenderX XEP client edition and will be supported through our community-based xep-support mailing list (http://xep.xattic.com/xep/lists.html). The edition is described in detail at http://xep.xattic.com/editions/academic.html . Qualifying parties willing to obtain a license are invited to contact RenderX at [EMAIL PROTECTED] David Tolpin RenderX --- End Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Updates to web site
Oleg Tkachenko wrote: Peter B. West wrote: You have to login to xml.apache.org, cd to /www/xml.apache.org/fop/...wherever... and perform a cvs update -d The -d, as I discovered, forces creation of any new subdirectories in the working copy. Actually I didn't add new subdirectories. And I have no access to xml.apache.org, only to cvs.apache.org. Can you please run that update for me? Done, by me and by Sam. 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: Integration of Peter's work
Jeremias Maerki wrote: On 01.02.2003 00:16:30 Peter B. West wrote: Should we reserve a directory on the web site for storing diagrams which find their way into the Wiki? +0. The other possibility is to put it in the public_html folder of your cvs.apache.org account. Even though I don't have any appropriate tools for such at the moment, I should like the diagrams to be editable to the same extent as the text. I don't comprehend design discussions without diagrams. In order to do this, we need somewhere accessible, not necessarily on the web-site, to drop these things. Can they be fitted within the Wiki structure? 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: Integration of Peter's work
Jeremias Maerki wrote: Hi all (and especially Peter) I'd like to ask if and when we can integrate Peter's work into the main redesign. If nobody is against this move in general, I'd volunteer to help Peter integrate it. I've got some time for this and I think this could help focus our limited resources. Peter, would you add a Wiki page describing what needs to be done for the integration and what others could help you with? Jeremias and others, Sorry about the delay on this. I'll start some work on the Wiki now that I have something basic working with my documentation. Should we reserve a directory on the web site for storing diagrams which find their way into the Wiki? 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]
Javascript for frames
Fopdevs,
Here is an extract of what I ended up with in the alt.properties frames.
In index.html (the frameset page)
script type="text/javascript"
// IE didn't seem to like "type application/x-javascript"
var isHigh = true;
function lengthenCol() {
if (isHigh) { return; }
fset = document.getElementById("altDesignFramesetRows");
fset.setAttribute("rows", "95%,*");
logowin = top.frames[0];
if (logowin == null) {
alert(
"Requires Navigator >= 7, Mozilla >= 1.2.1 or IE >= 6");
return;
}
logodoc = logowin.document;
lbutton = logodoc.getElementById("lengthenButton");
lbutton.setAttribute("value", "^");
isHigh = true;
}
// I have no idea whether the attempt to warn about browser type
// is valid, because i have no idea fo the point of failure for
// other browsers. Some advice on this would be useful
function displayCode(src) {
top.frames[2].location = src;
shortenCol();
}
function displayHtml(src) {
top.frames[1].location = src;
lengthenCol();
}
In logo,html, which contains the menu and the display toggle button, the
menu items are summoned by:
>PropertyConsts
and code display is triggered by html like
This class, and the singleton object which is
href="javascript:window.top.displayCode(
'PropertyConsts.html#pconsts' )">generated by the static
initializer, is essentially a repository of
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: Updates to web site
Peter B. West wrote: Fopdevs, I have been lost in the wilds of DOM for a little while now, trying to find some pleasant common DOM-ish way to make my alt-properties docs work in IE6 as well as Netscape 7/Mozilla 1.2.1. I am in the process of updating now, and would appreciate some feedback on a number of issues, including the javascript I have used, and ways of maximising the integration with Forrest. And of course, the docs themselves. Documentation of alt.properties is not yet complete, but the framework I want to use is in place. This is in place now. It seems to work with Mozilla and IE6, although the display toggle button is differenctly positioned in both. 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: Updates to web site
Oleg Tkachenko wrote: Hello there! btw, forgive my ignorance, but how do I get the site to be updated? I have generated one more page for logo contest and commited pages successfully to xml-site/targets/fop, but after 2 days the site is still not updated :( You have to login to xml.apache.org, cd to /www/xml.apache.org/fop/...wherever... and perform a cvs update -d The -d, as I discovered, forces creation of any new subdirectories in the working copy. PS. I've been sort of out of FOP dev last month due to heavy workload, but finally we've got next version of our product installed today and now I hope I have a chance to return to our great dude. I, likewise, have been on the margin since New Year. I blame the woman I met a the NY'sE party I attended, often. And I have moved to a new flat. 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: Updates to web site
Hmmm... looks as though the updates won't be in place until I have had some sleep. 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]
Updates to web site
Fopdevs, I have been lost in the wilds of DOM for a little while now, trying to find some pleasant common DOM-ish way to make my alt-properties docs work in IE6 as well as Netscape 7/Mozilla 1.2.1. I am in the process of updating now, and would appreciate some feedback on a number of issues, including the javascript I have used, and ways of maximising the integration with Forrest. And of course, the docs themselves. Documentation of alt.properties is not yet complete, but the framework I want to use is in place. 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: source for hz algorithm
Clay Leeds wrote: Does the idea that there would be intermediate results mean that a "human" could determine which is the best to perform the final layout? I'm thinking of a system similar to how some OCR programs enable the user to contribute to the process of recognition when the OCR program has problems determining a word or character. (FYI: OCR=Optical Character Recognition--used in scanning text-based documents which are converted to text for archiving, indexing, etc.). If so, could the implementation offer some way of "saving" the best method? I would think it would work like a userconfig file. I meant to add my reasoning. Since one can assume that generating multiple iterations will be processor intensive, if there existed some sort of "config" file identifying clues as to how the hz algorithm should proceed for a particular file, it would shorten the processing time, as well as ensure that the output was always the same. Clay, I don't see it this way. The multiple iterations occur within the rendering of a particular document. I saw the human intervention as a way of interactively deciding on one layout among a number of possibilities which the processor was unable easily to distinguish, not as some asynchronous event. While I can see the possibility of "learning" about the scoring of layout possibilities from such interactive input, I can't see that sets of rendering decisons need to persist. 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: source for hz algorithm
Clay Leeds wrote: Does the idea that there would be intermediate results mean that a "human" could determine which is the best to perform the final layout? I'm thinking of a system similar to how some OCR programs enable the user to contribute to the process of recognition when the OCR program has problems determining a word or character. (FYI: OCR=Optical Character Recognition--used in scanning text-based documents which are converted to text for archiving, indexing, etc.). If so, could the implementation offer some way of "saving" the best method? I would think it would work like a userconfig file. Clay, It's an interesting idea. It could be thought of as another User Agent (or User Agency) function. 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: source for hz algorithm
Rhett, If intermediate results from the FO tree and the Area tree are buffered to disk, the distinction between single pass with back-tracking and multiple pass begins to blur. For things like page number resolution a straight-forward multi-pass solution may be best, but I would like to see where we go with the other more localised problems before considering a full-on multi-pass model. Peter Rhett Aultman wrote: Peter, This brings back to light the possibility of needing to do multipass layout, doesn't it? I had suggested something along these lines previously. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 12:30 AM To: [EMAIL PROTECTED] Subject: Re: source for hz algorithm Layout sometimes occurs in an environment of known available BPDimension and IPDimension, sometimes with only one dimension, and sometimes with neither. In the latter cases, the layout process is effectively a probe to see what the dimensional requirements range for this piece of layout is. However, problems like rivers, last page and footnotes turn all layout into probes, and all layout must potentially be undone and redone in the light of the knowledge gained. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- 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: source for hz algorithm
Keiron Liddle wrote: True, but I had in mind that any such approach will be built on the fact that any layout is, in some sense, tentative. Rhett raised the question some time ago of a means recording (and scoring) intermediate results, something which will be an essential element of such a solution. At this stage, I would tend to think not of doing every possible layout, but of following the "optimum" values to perform initial layout, and then testing the result for "goodness". The minimum-maximum range provides the slack - within the context of the spec - for applying whatever other set of layout tuning algorithms that FOP implements. The idea I am working with (of which I have prototype working) is that a break is after a line. For this break it finds the BPD distance from the top down (flow layout manager) from the start of the page to the current break. I can't visualise the flow of control here. I presume that the break (possibility?) is generated at, say, line-area building level. [Is this always based on knowledge of the IPDim, or does the possibility exist of not knowing IPDim, but being prepared to report upward on the possibilities for IPDim?] Does the information about this break then percolate back up to the flow-level layout manager? Is the BPDim from top of page reported back to the line-area level, or maintained at the flow manager level? It also finds the keeps from the current break position, looking at parent layout managers and next layout managers for keep with previous. A best break is found based on these two values. A next break is then found, since we don't know we have a best until there is a worse break. This can be done for all pages in the page sequence or until forced break. This implies that the answer to my previous question is that the BPDim comes back down to the line-area level, and that keeps are resolved between adjacent line-area builders. Your notes here seem to be referring to column and page breaks. At what level is the contention between two or more line-area builders for "best break" resolved? Then if for example we want to find the optimum break. There is also the possiblity to get the next break within a context (which invalidates all further breaks) or previous break. Is this invalidating of further breaks something which is instigated from a higher level? I am quite confident that this will work well. Footnotes and before floats suddenly become easy. Keeps are quite easy also. It would be good to get some more illustrations of the way these will work. The only drawback is that it constantly needs to find the child layout manager that applies to a given break and that finding the BPD distance could be time consuming in some circumstances. Optimisations should help a bit. I would see these being arranged as a set of heuristics - for want of a better word - that are applied in a structured fashion to detected layout conflicts of particular types. What comprises a conflict would be determined by those configurable parameters. In the initial version, we only need to provide for the most basic of these, as long as the mechanism is general enough to allow for refinement. I am hoping that making the breaks simple and easy to find certain properties from any position will help us to explore what to do next. I think this is similar to what I refer to as threading the tree to establish which areas are contiguous in the output, both for keeps and space specifiers resolution. 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: source for hz algorithm
Oops. Peter Rhett Aultman wrote: I'd meant for him to contact me privately so I could mail him some photocopies and save him the trouble of trying to find copies of the book. -- 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: source for hz algorithm
Victor Mote wrote: Peter B. West wrote: These are interesting and important issues. I had no notion of the HZ algorithm, but I was dimly aware from my reading as a teenager of the "rivers" problem, and acutely conscious of its distracting effect from my reading. In my thinking about layout, I have been conscious of the need to be able to evaluate such issues at a high level. The only way such an evaluation can be done is by layout look-ahead. The page must be laid out before "rivers" can be assessed. (Finding them would be an interesting problem in itself - and no doubt part of HZ.) It actually would seem to go beyond look-ahead, and instead be more along the lines of laying the content out multiple times & scoring each one. True, but I had in mind that any such approach will be built on the fact that any layout is, in some sense, tentative. Rhett raised the question some time ago of a means recording (and scoring) intermediate results, something which will be an essential element of such a solution. At this stage, I would tend to think not of doing every possible layout, but of following the "optimum" values to perform initial layout, and then testing the result for "goodness". The minimum-maximum range provides the slack - within the context of the spec - for applying whatever other set of layout tuning algorithms that FOP implements. I would see these being arranged as a set of heuristics - for want of a better word - that are applied in a structured fashion to detected layout conflicts of particular types. What comprises a conflict would be determined by those configurable parameters. In the initial version, we only need to provide for the most basic of these, as long as the mechanism is general enough to allow for refinement. One of the articles that Rhett pointed out indicates that Karow was working on a "chapter" level optimization -- probably equivalent to a page-sequence for us. It would seem easy to have several thousand or more possible layout options for an expanse that big. One issue in implementing this kind of thing is to make it configurable, or even to make specification part of the standard. A lot of on-the-fly web-based users won't want to spend the hardware resources to get output this finely tuned, but those of us who are generating high-quality static content won't mind. In other words, we need quick-and-dirty solutions that are optimized for speed to be able to coexist with more complex solutions that are optimized for quality. Part of what triggered my thoughts here was a thread on the XSL-FO list in which it was stated that XEP takes about 3 times as long to run as FOP. There are a lot of possible reasons for this (including implementation of features that we don't have yet), but it is possible that they have implemented some better H&J work. I don't intend to implement any of this any time soon, but I need to let some of the concepts sink in for a while, so I thought I had better get started, in anticipation of (hopefully) getting back into FOP code again within about a week. -- 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: source for hz algorithm
Sebastian Rahtz (PassiveTeX) would be a good source of information. I think he tends to hang around on [EMAIL PROTECTED] Btw, URW provide one of the best-known set of free Type1 fonts for linux. Peter Victor Mote wrote: J.Pietschmann wrote: The TeX-Book has a chapter about this problem. It is available as textbook.tex (in TeX, and quite officially). Amazingly, I didn't find it on CTAN, but a google search turns up other servers (I can send you the 460k compressed source). I think it is also Volume A of Knuth's "Computers & Typesetting", which I hope to receive shortly. I am hoping not to have to stop and become a TeX user along the way, but I think it is worth learning as much as is morally possible from them. BTW, I looked for but did not find licensing information at tug & ctan licensing information, as well as in my Norman Walsh book "Making TeX Work". Does it use a GPL? If it had a compatible licensing scheme, it would sure seem to make sense to use as much of the TeX work as possible. -- 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: source for hz algorithm
Rhett, Discussion of the actual algorithms would be of general interest, I think. Peter Rhett Aultman wrote: My girlfriend just located both volumes at the University of Central Florida library and is bringing them home for me to peruse. Vic, why don't you email me privately so we can discuss this? -Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]] ... It is documented in either book 1 or 2 of Digital Typography by (I think!) P. Karow, of URW (i.e. the folks behind the Ikarus format (just google for URW and Digital Typograhy or Ikarus)). I think it is in book one. The books are an absolute 'must have' - but hard to get. Occasionally one can be found second hand; usually from a art/font firm dealing with the high end market of posters and other big print publications. But the algorithm described there is not a computer one; but more a method for someone cutting the scripts coming out of the linotypes and pasting them on the wax board. -- 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: source for hz algorithm
Victor, These are interesting and important issues. I had no notion of the HZ algorithm, but I was dimly aware from my reading as a teenager of the "rivers" problem, and acutely conscious of its distracting effect from my reading. In my thinking about layout, I have been conscious of the need to be able to evaluate such issues at a high level. The only way such an evaluation can be done is by layout look-ahead. The page must be laid out before "rivers" can be assessed. (Finding them would be an interesting problem in itself - and no doubt part of HZ.) Layout sometimes occurs in an environment of known available BPDimension and IPDimension, sometimes with only one dimension, and sometimes with neither. In the latter cases, the layout process is effectively a probe to see what the dimensional requirements range for this piece of layout is. However, problems like rivers, last page and footnotes turn all layout into probes, and all layout must potentially be undone and redone in the light of the knowledge gained. Peter Victor Mote wrote: Hello all: I have been looking for some time for a source for the HZ (Hermann Zapf) algorithm which (as I understand) optimizes line breaks for multiple lines, looking for rivers, too many lines in a row ending in hyphens, etc. I think I first saw it referenced in Bringhurst's book, and that it was implemented by a European company that is now out of business. I understand that TeX implemented it or something similar, and that Adobe may have used the TeX algorithm in InDesign. The closest thing I have found to a source for the algorithm itself is that Knuth's "Digital Typography" may have it or at least a discussion of it. Do any of you have additional information on this, such as how to find the algorithm itself? Is it patented? Along these same lines, I recently acquired a book that may be helpful to others -- James Felici's "The Complete Manual of Typography" (Adobe Press) has a lot of good information both for users and developers. Chapter 10 on H&J was especially useful, and somewhat prompted the above questions. Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice +1 (719) 622-0650, Fax +1 (720) 293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- 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: Problems with the website
Jeremias Maerki wrote: Hi Peter On 25.01.2003 03:30:19 Peter B. West wrote: How about using a popup window instead of the frames approach? (Disclaimer: Don't know a lot about HTML/JavaScript and such) Jeremias, That was my first attempt. I used th tag, well supported in Forrest. However, I found teh results cumbersome, which is why, in spite of the problems, I have gone for the frames solution. The more immediate problem is that I can't get the website to update correctly. I have done an update, the necessary adds and the commit on the site; cvs status tells me that the files are all up-to-date, yet when I do an update on the site itself, I get a Not Found when I try to access the fop/design/alt.design/properties/index.html. Does anyone have any idea what might be going on? I have tried to figure it out, but no luck here either. CVS looks ok. Everything works locally. I can only imagine that something went wrong with the synchronization of icarus and daedalus. cvs update -d The default cvs settings do not include a -d, so the new directory was not being updated. Now to find out how to make this work with IE, or IE 6 at least . 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]
Problems with the website
Fopdevs, I have been hacking away at the documentation, and in particular at the alt.properties implemetation description. As part of that, I have tried to develop a framework with an integrated code view. At this stage it is fairly rudimentary and messy, and does not integrate at all well with Forrest. By means of some nasty kludges, I have managed to get a recent build of Forrest to construct the site without complaint. I am using XEmacs to generate html versions of some java files with coloured syntax, which are the sources for my code display. To integrate them into the referring pages I am using frames and javascript. I have just seen Chaperon, and the coloured Java sources that Stephan Michels is generating in his Cocoon javadocs. Stop Press. Nicola Ken has just introduced me to JavaSRc, as used in http://jakarta.apache.org/poi/javadocs/javasrc/ which looks the goods. When I sort out how to use it, it can be integrated into the forrest build, and I won't need to coloured code separately. This is my first attempt at javascript, and I had naively hoped that the browser differences had been eliminated. I will separately post the current javascript and seek advice on how to browser-proof it. The more immediate problem is that I can't get the website to update correctly. I have done an update, the necessary adds and the commit on the site; cvs status tells me that the files are all up-to-date, yet when I do an update on the site itself, I get a Not Found when I try to access the fop/design/alt.design/properties/index.html. Does anyone have any idea what might be going on? 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: Integration of Peter's work
Jeremias Maerki wrote: On 23.01.2003 12:34:33 Peter B. West wrote: ... There are a couple of issues in the design of the properties code that will require decisions from the editors. I will detail these on the Wiki, and formulate questions for the editors in hopes of a quick reply. I don't think that each and every issue has to be resolved prior to move your things in. We can sort that out later, right? Or are there any showstoppers? Mess-makers. We will need to think about the sorts of changes that will be required if the decision goes against me. ... I don't want to put pressure on you. Just know that I'm available if you're ready. Much appreciated. 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: Integration of Peter's work
Jeremias, I shall do that, although, never having had anything to do with Wikis before, I will be fumbling. As you may have noticed, I have been somewhat distracted since the New Year. Among the things that require attention are my attempts at a pseudo-code-walkthrough style of documentation for the properties code. I hope to post my initial efforts tomorrow. I have struggled to make the documentation acceptable to Forrest, but the end result is not satisfactory, and I am hoping for some detailed suggestions once I get the pages up. There are a couple of issues in the design of the properties code that will require decisions from the editors. I will detail these on the Wiki, and formulate questions for the editors in hopes of a quick reply. Those things aside, the integration can probably proceed along the same vector as the current FO Tree integration - via the completion of page-sequence events. What will be interesting here is the possibility of defining a set of structure events for integration with the structure renderers like RTF, and I hope we can have some fruitful discussions with Bertrand on this. Warning: extensive style policing will be required. A bit to do over the next few days. Peter Jeremias Maerki wrote: Hi all (and especially Peter) I'd like to ask if and when we can integrate Peter's work into the main redesign. If nobody is against this move in general, I'd volunteer to help Peter integrate it. I've got some time for this and I think this could help focus our limited resources. Peter, would you add a Wiki page describing what needs to be done for the integration and what others could help you with? -- 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: [Fwd: xml.apache.org refactoring #1]
Keiron Liddle wrote: Personally I would like to see some sort of rotation (assuming that there will always be 1 or 2). For example every 6 months. Why? So the PMC becomes something that is better known and diverse than the mystery that it currently seems to be. This is an excellent idea. 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: [Fwd: xml.apache.org refactoring #1]
Jeremias, Without going back to the original posting, I suspect that the PMC does not want to have to sort out candidates. It is our job to decide on two nominations to the PMC, which the PMC intend, IIUC, to simply accept. I haven't followed the discussion beyond that, and I nominated only because we needed another nomination, and because, on reflection, it would look good on the CV. I hope this is not too crass an admission for the FOP sensibilities. I'm not sure that the comment on releases is entirely accurate. It seems to me tha the responsibilities of the PMC are much braoder than that, but I may be wrong. What I thin kis more pertinent is that the PMC meets monthly. This is presumably an on-line meeting, but using what facilities? I am on the end of a state-of-the-art 33k dialup link, and I wonder if this would cause problems. In any case, it's up to us to work out who we want our representatives on the PMC to be, and forward one or two names. That's my take on the matter. Peter Jeremias Maerki wrote: Deperated volunteers? I can do without, I was just taking responsibility because nobody wanted to take the first step. :-) I really don't know. If you look here:http://xml.apache.org/management.html. The PMC elects new members. So in theory all we can do is provide candidates, but obviously not all of us are well known to the current PMC members. So how would the they choose? They might leave that to us. I don't know. One point I'd like to make is the following: Christian is our current release manager. Since the PMC role has a lot to do with releases, he is an obvious candidate IMO. That doesn't mean I should be the other just because I volunteered first or something like that. This is one objective point for Christian and zero for Peter and me. Common guys! I'd like to have some participation on this matter from all the committers since this an important thing. On 21.01.2003 13:38:47 Oleg Tkachenko wrote: Ok, we've got 3 desperated volunteers. Should we vote? -- 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: [Fwd: xml.apache.org refactoring #1]
Jeremias Maerki wrote: I'm for having two. Takers? On 21.01.2003 00:12:58 Peter B. West wrote: Next question: should we go with 1 or get another nomination? Ok. I'll put my hat in the ring. 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: Ready for 0.20.5 from my side
Jeremias Maerki wrote: Can't we do it in a way that the history gets copied? That way, people downloading an old revision will have both src/org and src/java/org locally, so it uses a bit more storage capacity but still build. Is that doable? On 15.01.2003 19:41:51 Oleg Tkachenko wrote: Jeremias Maerki wrote: I'll continue to do the directory moves in the redesign and I'm still hoping for a volunteer to do the server side move/copy of the src/org directory to src/java/org. It's easy, but we'll loose ability to build old revisions then (didn't we yet?). If it's not an issue, all we have to do is to move the directory within the repository and massage CVSROOT/history, that's it, isn't it? Well, I'm going to try on local cvs first with xml-fop module. I already have three trees - HEAD, maint and alt. The main thing is that particular distributions be reproduced. Make sure the complete tree is tagged just before the move. Then, when things are moved, you take the trouble to add a "Moved from ... tag TAG" comment to the cvs add phase, the trail can always be followed back from the cvs log. I don't know whether the same can be said of cvs remove. I've never tried it. 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: [Fwd: xml.apache.org refactoring #1]
Jeremias Maerki wrote: I'd volunteer if nobody else wants the job. On 20.01.2003 11:48:31 Oleg Tkachenko wrote: Christian Geisert wrote: From: Ted Leung <[EMAIL PROTECTED]> We ask each subproject to nominate 1 (or 2) people from that project to be a part of the XML PMC. From my experience, I think that it will be better to have 2 people rather than one in order to share workload, etc. So, they want 2 people, I believe it's not a problem for us to elect them, let's start - candidates? Jeremias, +1 Next question: should we go with 1 or get another nomination? 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: File size improvements for PS renderer
Jeremias Maerki wrote: If it works, I have nothing against it. Likewise. Peter On 16.01.2003 13:10:13 Christian Geisert wrote: Arnd Beißner wrote: Hi Jeremias, I just submitted the PS renderer fix/enhancement I recently mentioned to BugZilla, bug #16130 [..] Hope you can still get this into 0.20.5, I just tested your patch and it looks good. I'm inclined to commit the patch. Other opinions? -- 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]
Feeding the dogs
tation of certain design features. At least one can proceed. If every implementor faced the same situation, there would at least be a rueful solidarity among all of them. This is not the case for those implementors who are also editors. All other things being equal (which they are not) the simple fact that an implementor-editor is able to argue for an interpretation directly to the other editors endows an enormous advantage. In addition, of course, the implementor-editor has access to the internal channels of communication among the editors, and amongst the subgroup of implementors. This access bestows the multiple advantage that those involved in implementation can kick the issues around in at least email time, can draw other editors into their deliberations, and can make joint representations in behalf of their interpretations to all of the other editors. I have no idea whether these forms of discussion actually occur, of course. If they do, they represent an impost on all other implementors. If they do not, I propose that they should be created, with one significant difference: the implementation channel should be open to all implementors. The rationale is simple, and extends the rationale of requiring implementations before promoting PRs. Implementors create the testing lab and reality check for proposals, and perform shakedown testing for intelligibility, winkling out all of the ways in which a statement or set of statements can be read. The way to maximise the efficacy of the process is to maximise the interactive input by maximising the number of implementors involved. By this means, other implementors have the opportunity, both to hear the rationale of those who are closest to the process, and to argue with them for other interpretations and modifications. This combined implementation experience then comes to the full formal meetings of the editors though the editor-implementors. Outside implementors, noting the opinions and arguments of the editors on the list, can then make informed interim decisions about their own designs. It goes without saying that the editors remain free to take whatever decisions they choose in the various publication milestones of the spec. Of course there would be issues about how to moderate such a group, how to determine membership, etc. My own view is that a group considering technical issues of the specification in such detail would be self-moderating, and that it would be sufficient, at least at first, to create an open list. The presupposition here, of course, is that the editors, and more particularly the implementor-editors, are interested in free and open discussion of these issues; that no-one has an axe to grind. Which brings me back to the beginning. We have seen that corporate self-interest interferes with the normal courtesies of developer communication in the open source environment. The larger question is whether corporate representatives on editorial boards such as this are free to seek the common good in the development of standards for the X-Web. Peter This message is also being posted separately to the [EMAIL PROTECTED] list. -- 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: Ready for 0.20.5 from my side
Victor Mote wrote: Jeremias Maerki wrote: I'll continue to do the directory moves in the redesign and I'm still hoping for a volunteer to do the server side move/copy of the src/org directory to src/java/org. I'll be glad to help with the server side move/copy. AFAIK, a simple Unix mv/cp should do the trick on the server side. My preference is to use cp & then move the old stuff to the attic after the dust settles (that will cost us only about 21 MB of disk space). The real issue is that /everyone's/ sandbox is messed up by this, so it is worthwhile to coordinate this so that everyone can get changes checked in (or moved aside), blow away their sandbox, & get a clean sandbox after the surgery. Also, it would be good to know that we could get our repository restored if something went wrong -- do we know how to do that? Victor, Oleg, My distinct preference would be to do this in the boring, staid old fuddy-duddy way (that's the kind of guy I am.) Go through the motions of local move, cvs remove, cvs add and cvs ci. This is the way with the least complications. If the issue is 100Mb of disc space, then the system desperately needs another 50Gb or so of disc. We can all donate $5 and give it to the ASF. 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: thoughts on fonts (was: text-decoration)
Victor Mote wrote: Jeremias Maerki wrote: It is very possible that I am missing something, but our memory-lean event-based model would seem to dictate either 1) parsing the document twice, or 2) not allowing multiple output formats in the same document. I think my approach could work in this regard. I'm not sure. We can let the FO tree live for another layout run, can't we? I have no objection to it. However, AFAIK our processor doesn't really process an FO tree, it processes events that occur as the FO tree is built. So, you need to add something that walks through the existing FO tree & starts creating events to feed into our processor. I don't know how much faster this might be than just reprocessing the original input. Then you need something in the process that says "Oh, don't try to build an FO tree here, it already exists." In other words, we're kind of trying to reuse something that we didn't use the first time -- it all seems kind of klunky. It seems to me that if we want to go down that path, we would do well to build an FO tree up front, caching it for those who need a lean memory environment, then process that tree n times, all the same way. I am not really arguing for that, but merely pointing out that it seems like that is where reusing the FO tree leads us. There's one in alt.design if you ever need it. 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: [PATCH] doc validation fix
Victor Mote wrote: We're OK. I caught your irony. My response was really entirely to Oleg's question. However, I really was concerned about offending someone -- things like names and logos carry a certain emotional weight. In other words, I might worry about offending some on this list, but it really wouldn't bother me to offend you at all, Peter. VVBG :-) Touche'. 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: FOP logo
Ralph LaChance wrote: At 04:34 PM 1/13/03, you wrote: Maybe. But IMHO the letters "FOP" should be easily readable and the whole logo shouldn't be too overloaded with additional stuff. Yes, but that still leaves quite a bit of room for font experimentation. I cannot resist - How many programmers does it take to change a logo ?|;^) NaN In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) You've found the attribution. One of my favourites. 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: FOP logo
Bernd Brandstetter wrote: On Monday 13 January 2003 11:01, Oleg Tkachenko wrote: Bernd Brandstetter wrote: feeling inspired by your's and Oleg's suggestions and also a little bit bored this Sunday afternoon, I thought I'll take the chance and improve my Gimping skills. Here's the result :-) Not bad. Something like this I meant. But (sorry for being critical, it's art, not coding :): why it's sitting back to us. No problem :-) This was in no way meant to be a serious proposal for the logo. I've also created one with a parrot sitting with it's front to us. However, I found this one with it's impish look back over the shoulder much nicer. I agree. It's more interesting that way. F and P are too simple. Maybe. But IMHO the letters "FOP" should be easily readable and the whole logo shouldn't be too overloaded with additional stuff. Yes, but that still leaves quite a bit of room for font experimentation. 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: [PATCH] doc validation fix
Victor Mote wrote: It must be a cultural thing. The dictionary definition you gave should tell the story well enough -- see the example "felt contempt for the mincing ...". The word is a pejorative, but perhaps more so in my part of the world, where calling someone a "fop" or a "dandy" might be fighting words. In my mind it connotes "sissy" on one end of the scale and "big hat, no cattle" on the other. This is all partially mitigated by the fact that the word is pretty much in disuse, so maybe nobody else knows what it means. Finding myself in the minority, I withdraw the question. I intended no offence. As a workaround, please don't be offended if I continue to treat the name as an acronym instead of a word. Victor, Re my comment on this, I thought I should warn you that I am addicted to ironical jokes, which can be a dangerous habit with email. I dislike emoticons, probably because I am more of a snob than I like to admit, but also because they seem to me to discourage any attempt either to write or to read the subtle - or the ironical! - from email. An advantage of the longevity of a forum like this is that we get to know each other's style, so I hope that my un-emoticoned attempts at humour are read as such. I'll see if I can squeeze one out. ,; :) >;, 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: [PATCH] doc validation fix
Victor Mote wrote: Jeremias Maerki wrote: - Do we like our current logo? :-) I hope I am not out of line to ask an even more fundamental question -- do we like our current name? I never have a problem writing it, but when speaking it, I cannot make my mouth say "fop", but invariably say "eff-oh-pee" instead. Heresy! Victor, the stigma that once attached to consulting a speech therapist has almost vanished now. I'm sure something can be done, and our best wishes will go with you. 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: FOP logo
J.Pietschmann wrote: Oleg Tkachenko wrote: Jeremias Maerki wrote: - Do we like our current logo? :-) Uh! Should admit I spent a couple of hours trying to implement my ideas about the logo (leading motifs were medieval typographic dropcaps and a parrot as (imho) the most foppish animal) but I'm too bad artist and the results were too ugly :) What about a TeX-parody? +--- +--\ | | | +-- /--\ +--/ | || | | || | || \--/ Colored as the current logo, or more in shades like the Apache feather? (feather - part of a parrot - hmm) Clare's designs (see previous post) were based on a quill inking in the "P" in a large "FOP" on a page which also contained Chancery-stle text in a smaller font. The quill was originally supposed to be a connection with the Apache feather, but apparently that particular feather "didn't work", and the Apache colours were too garish. 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]
FOP logo
Oleg Tkachenko wrote: Jeremias Maerki wrote: - Do we like our current logo? :-) That's a big question actually :) afair Keiron said the current logo should be at least brighten to fit forrest-ed site design better or suggested to make the logo contest. Should admit I spent a couple of hours trying to implement my ideas about the logo (leading motifs were medieval typographic dropcaps and a parrot as (imho) the most foppish animal) but I'm too bad artist and the results were too ugly :) My suggestion is to announce the new FOP logo contest in fop-user list or broader, like recent Amaya welcome page contest[1] (the winner gets bragging rights). Then we can vote among developers or users, how the idea? [1] http://www.w3.org/Amaya/contest.html I mentioned the need for a logo some months ago to an acquaintance of mine who is a graphics design student. She came up with some interesting ideas, but they were incomplete the last time I spoke to her (just before Christmas.) I will try to get in touch with her again, and get her to post some of her sketches for comment. 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: thoughts on fonts (was: text-decoration)
Victor Mote wrote: There are some big picture things that we should probably address: 1. (Biggest of all) Do we have users that need to be able to do this? Are the performance gains that they might get worth the pain on our end? Apart from this is the fact that our processing model for any rendering is still very much in a state of flux. It may be less painful to retro-fit when we have a comprehensive working renderer, keeping this possibility in mind as we go. 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]
Cleanups in enumerated-values.xml
The elements obviously had to be cleaned up, but I am little saddened that the elements have been compressed. I have tended to use the spaces when I find myself with long sequences of characters which do not wrap easily. Judiciously applied spaces provide multiple wrap points for the folding algorithm. 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: FOP Style Guide (update)
Arnd Beißner wrote:
Jeremias Maerki wrote:
The following should (sorry, could) be ok:
for (int i = 0; i < 5; i++) {
doSomething();
if (amIRight()) cool();
doSomethingElse();
}
One point here:
If it's not amIRight() but
if (amIRight() || ( more stuff follows .) cool();
doSomethingElse();
you tend to ignore the cool() stuff in favor of doSomethingElse.
Yep. It takes an eye for layout, which seems appropriate.
I can't count the times I've seen people hunt for this kind of
bug (most when changing someone else's code, of course).
Which is why I always use:
if (foo)
doFoo();
On the whole I think you would be served best by forbidding
if (foo) doFoo();
and allowing
if (foo)
doFoo();
else
doBar();
as well as
if (foo) {
doFoo();
}
else {
doBar();
}
leaving this issue to personal taste.
This man must be one of them there anarchists.
Just my 2 cents.
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: FOP Style Guide (update)
J.Pietschmann wrote: On 08.01.2003 14:23:36 Peter B. West wrote: And it adds just a spice of danger. I can live well without this. Spoilsport. 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: FOP Style Guide (update)
J.Pietschmann wrote:
Peter B. West wrote:
if (isEnabled()) {
return true;
}
is absurd.
Not necessarily. I it *much* easier to add a
System.out.println() to this than to either
if (isEnabled())return true;
or
if (isEnabled())
return true;
Agreed.
If you are debugging code written by someone else,
this should be worth the trouble of the additional
line with the closing brace.
When I add the println, I also add the braces. The motivation for
eliminating the braces is the readability of the code when there is only
one line, which is a very frequent occurrence. It comes to a balance of
motives and requirements.
I like to have as much code as possible in my viewing window, but I also
like to scatter blank lines about - readability again, to this jaundiced
eye. These conflicting demands are one reason I'm so fond of compact
one-liners.
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: FOP Style Guide (update)
Jeremias Maerki wrote: Or if checkstyle could also check indentation... *That* would be extremely useful, and would solve the problem. Maybe a Python preprocessor Joke, folk. 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: FOP Style Guide (update)
Christian Geisert wrote: Peter B. West wrote: Jeremias Maerki wrote: Since I've made the checkstyle.cfg file an integral part of our style guide I have to bring this up before changing: I'd like to add a line "checkstyle.ignore.braces = yes". This enables one line ifs like the following: [..] if (isEnabled) doOneLiner(); else return false; which is easier to read than if (isEnabled()) doOoneLiner(); else return false; And what about this: if (isEnabled()) doThis(); doThat(); Yes, I like explicit braces. For the above reason, which is the primary argument for them. It's usual expression would, I think, involve changes to the code, so that what started as if (isEnabled()) doOneLiner(); else doOtherOneLiner(); becomes if (isEnabled()) doOneLiner(); else doOtherOneLiner(); oopsForgotThisOne(); which errors can be hard to find when the indentation confuses the issue. Nonetheless, I prefer the braceless style for one-liners, because it is easier to read, IMO. And it adds just a spice of danger. 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: FOP Style Guide (update)
Jeremias Maerki wrote:
Since I've made the checkstyle.cfg file an integral part of our style
guide I have to bring this up before changing:
I'd like to add a line "checkstyle.ignore.braces = yes". This enables
one line ifs like the following:
if (isEnabled()) return true;
Without this line, you have to write:
if (isEnabled()) {
return true;
}
Please speak up if the change is unwelcome. Thanks.
Jeremias,
The change is most welcome.
if (isEnabled()) {
return true;
}
is absurd. However, if I can do
if (isEnabled()) return true;
should I not be able to do
if (isEnabled() && someOtherVerboseCondition())
return true;
and also
if (isEnabled)
doOneLiner();
else
return false;
which is easier to read than
if (isEnabled()) doOoneLiner();
else return false;
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: Documentation woes
Joerg Pietschmann wrote: Hi all, I think there are still some problems with regard to our documentation. 1. There is a src/documentation/content/design/alt.design with some HTML files 2. There's also a src/documentation/content/xdocs/design/alt.design with some more XML files 3. Furthermore there is a docs/design/alt.design with even more files, apparently diagrams and figures. This keeps confusing me: is it forrest which forces these files to be scattered all over the directory structure? I'd think they could be a) better grouped together b) better separated from the other documentation files. If this is all caused by Forrest, I'm disappointed with this tool. Having a foul mix of docs for HEAD and the maintenance code is bad enough, but having examples, downloadable ressources, graphics and SVG and finally the docs for another code branch scattered all over the place is too much for me. Joerg, The current state of the alt.design docs is partially a result of my pressuring Keiron to migrate the docs across. I am in the process of updating and extending that documentation. I will look to removing the remaining files from docs/design/alt.design in the next week. At the moment these are source files for dia, which I was using to generate some diagrams. Most of them will be removed, but some will survive, and will have to find a home, with other diagram sources (e.g. OpenOffice drawing files) in the src/documentation tree. The HTML files in src/documentation/design/alt.design will remain as part of the alt.design documentation, taking advantage of the recent resolutions in forrest-dev. They are generated with htmlize.el plus a short perl script which was necessary because of my lack of elisp skills. It's the only way I can see to achieve the documentation results that I want, but I'm not the only one to require files generated outside forrest. So, 1) Yes, as explained above, and necessary whenever forrest cannot generate the particular file you want; 2) The standard approach which provides the framework for the alt.design documentation; 3) A historical artefact, which will soon go away. 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: Integrating Javascript with Forrest
Jeff Turner wrote: With the CVS version of Forrest, you can place raw HTML/PDF/whatever files in src/documentation/content/, and (if linked to) they will be copied across. I've just updated the 'seed' project to demonstrate this. Jeff, Thanks for the update. I suppose that frames are, in principle, incompatible with the Forrest approach, and so incorporating them in subsets will always have to be done this way. I imagine, also, that the use of javascript URLs as hrefs presents great difficulties. 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]
Integrating Javascript with Forrest
Fopdevs, In trying to set up the alt-design documentation, I was initially hacking the forrest ant scritp to access pre-formed html. There is a vigorous discussion going on on forrest-dev about formal mechanism for this, so it looks as though, for the time being, I will be able to do this with a standard forrest. I was also using the "fork" tag for certain effects, but it proved cumbersome. I eventually decided that a combination of frames and javascript was necessary. (My first experience of javascript, I must say.) My question to the forrest-experienced here is: can frames and javascript be integrated into forrest? 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: bidi in the branch
Oleg Tkachenko wrote: Peter B. West wrote: I would encourage Oleg to bring this functionality into HEAD. If it already exists in Oleg's working copy of the maint branch (for reasons which have frequently been canvassed here), I think it would be churlish of us to deny access to our faithful band of users. May be, but as I said it's neither full nor effective and clean support (because I didn't dare to make any significant changes in LineArea addText() code etc) and + I exploited Sun proprietary sun.font.Bidi class, which is substituted by java.text.Bidi in 1.4. And main concern is that we are in the middle of the release candidate testing, so introducing any new potentially buggy functionality is not a good idea. Oleg, Yes, of course, it would not go in while we have an RC out there. If you are not happy with the state of the branch code, there's not much point pursuing it. 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: bidi in the branch
Jeremias Maerki wrote: Hi Peter On 20.12.2002 00:30:13 Peter B. West wrote: Jeremias Maerki wrote: :-) Ok, you're sentenced to implement the same functionality in the trunk. I'm -0 for the inclusion in the branch as it sends the wrong message IMO. But I'm looking forward to seeing bidi support in action in the trunk. Jeremias, I would encourage Oleg to bring this functionality into HEAD. Didn't I? :-) Yes; right above. Call my comment an extended +0 for the sentence you imposed. If it already exists in Oleg's working copy of the maint branch (for reasons which have frequently been canvassed here), I think it would be churlish of us to deny access to our faithful band of users. I would agree was it not for something that is an argument for the redesign. And read again, please. I wrote -0, not -1. I don't deny anything to anybody, just expressing an opinion. Same here - just an opinion. That's why I went for a +0. So, fop-0_20_2-maintain +0. 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: Happy Holidays
Keiron Liddle wrote: On Thu, 2002-12-19 at 16:30, Arved Sandstrom wrote: I'd like to wish everyone here happy holidays, whatever is appropriate. Happy summer solstice, happy winter solstice, happy Hanakah, and of course, happy Christmas and a happy, peaceful and prosperous New Year. (We live in hope.) At least... This is a good crowd. +1 :-) +1 Regards, Arved Sandstrom 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: bidi in the branch
Jeremias Maerki wrote: :-) Ok, you're sentenced to implement the same functionality in the trunk. I'm -0 for the inclusion in the branch as it sends the wrong message IMO. But I'm looking forward to seeing bidi support in action in the trunk. Jeremias, I would encourage Oleg to bring this functionality into HEAD. If it already exists in Oleg's working copy of the maint branch (for reasons which have frequently been canvassed here), I think it would be churlish of us to deny access to our faithful band of users. So, fop-0_20_2-maintain +0. Peter On 19.12.2002 18:11:02 Oleg Tkachenko wrote: Hello there! I know, shame on me, shame on me, but I've implemented partial bidi support in the branch. Sorry, it was urgent commercial requirement. It seems to be working ok (QA is still verifying it though), but of course it's a patch actually and I don't like it much. My question is: should I commit it to the branch codebase? I'm inclining to implement it in a clean way in the trunk instead of extending/patching the branch. -- 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]
Sorry about the commit
Fop-cvsers, Sorry abou the huge single commit. Has the commit mail behaviour changed recently? I though that commits of new files did not list the contents. 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: Sun XSL Formatter
Peter S. Housel wrote: "Arved Sandstrom" <[EMAIL PROTECTED]> writes: Well, Java or C or C++ or Haskell, it would have been nice to have a clue. We have an ASF tradition of developing communities...this kind of stuff that Sun and IBM does is getting old. Don't open-source it; sell it. I will argue against its adoption into Apache. Googling for xmlroff yields: http://www.plurb.com/webservices/UBL4.pdf Looks like they want to donate it to Gnome, not Apache. Despite your not wanting to sound bitter, your protest still sounds bitter anyway. Peter, Arved, In spite of Arved's protestations, I think he has reason to be bitter. I don't want to criticise a particular company, and especially not any particular individuals, but I think this incident underlines some endemic problems in the relationship between the corporate software world and the Open Source world. I am well aware of the enormous contributions to OSS of various corporations (Sun, IBM and Netscape spring immediately to mind.) I think, however, that these problems extend right into the standards development process itself. I should like to ponder these issues a little longer, and then perhaps take them up in a wider forum. 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: Sun XSL Formatter
Arved Sandstrom wrote: Not to sound bitter, but it would have been nice to know about this sooner. This pretty much usurps what I and Eric Bischoff have been doing (when we can); I sort of figure it didn't get written in the last month either. Any reason for the blasted secretiveness? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Subject: Sun XSL Formatter Peter did ask... Tony, Thanks for the response. I must say, though, that had the product been written in Java, I would have been asking the same question as Arved. 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: orphan/window control, blind tables, keep-with-next etc
Eddy De Clercq wrote: Hi, I've seen in the archives in the FOP mailing list lots of threads concerning this matter. Is there any news/update on when features like orphan/widow control, keep-with-next will be implemented in FOP (and Cocoon)? Eddy, Wait for about a day, then see what Sun has come up with. 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: dtd catalog (was: src/documentation/README)
Victor Mote wrote: Peter B. West wrote: ... The way this works is that your validation software has to know how to find the catalog. If it does, then the catalog can contain mappings from the PUBLIC IDs in the DOCTYPE declaration to a local physical file. That setup is already in all of our documents. For example, our resources.xml file contains the following DOCTYPE: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/sche ma/dtd/document-v11.dtd"> Your catalog has to know how to map "-//APACHE//DTD Documentation V1.1//EN" to "/u/xml-schema/document-v11.dtd" or whatever your local file is. What I added several weeks ago was the URIs (yes, they are CVS-based until we find some static URI to use instead) that allow the validation to be done across the internet. This doesn't take away the ability to use a local catalog, but rather makes it no longer a necessity. My understanding is that using URIs is the preferable way to do the validation. O'Reilly's "XML in a Nutshell", 2nd edition, page 32, says "In practice, however, PUBLIC IDs aren't used very much. Almost all validators rely on the URI to actually validate the document." The only reason to use the catalog and the PUBLIC ID is if you are on a machine that doesn't have suitable net access. These can (probably will) get out of sync. The dtd should be the one used when the document was last modified, shouldn't it? It seems to me there is a case for including the schema subtree, including catalog file(s) and the dtd subdirectory, in the src/build tree, and maintaining the synchronization locally. It seems to me, on reflection, that I had this completely wrong. They can't get out of sync *while they have a PUBLIC identifier.* I am still naive about such things, but doesn't the assignment of a PUBLIC ID ammount to a contract that the document so named will never change? If you want to change it, you must assign another PUBLIC id, because people all over the net are relying on the constancy of the association between the original PUBLIC id and the actual document. That means that it is perfectly safe to keep local copies of the documents, as long as you get the association right. Keiron & I discussed this at the time: http://marc.theaimsgroup.com/?l=fop-dev&m=103726556406364&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=103726721907599&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=103730698919444&w=2 and decided against it. Since I did this work, I see that we could use viewcvs to get a specific revision of the file, so we could control this using that method. However, it seems to me that DTDs conventionally have a version number built into their filenames, so I assume that any changes made on those files are of a bug fix nature as opposed to radical changes that would be likely to mess up users of the DTD. I reviewed this exchange, and found that we had the same concern; a desire to be able to make changes to the documentation without having to have a local forrest installation for validation and rendering. Your (and Keiron's) initial suppositions about this were the same as mine. I don't understand what went wrong when Keiron tried this, > http://marc.theaimsgroup.com/?l=fop-dev&m=103726721907599&w=2 but I wonder if cocoon is misbehaving by using the SYSTEM id instead of the PUBLIC id. Unfortunately it does work like that. To get the verification to work I need to add just the local public ID, so it uses the forrest one to verify forrest ID's and the local one for the local ID. Then when it is copied across cocoon can only find the ID for the fop dtd and the others are missing. If I put all the forrest+fop ID's in the catalog then it cannot verify as it cannot find the forrest dtd's relative to the catalog. Keiron, when you say "local PUBLIC id", are you referring to last component of the PUBLID id, containing the SYSTEM url? If a local copy of all of the forrest DTDs were maintained, and the FOP catalog pointed to that, then the problem of rendering locally or rendering remotely would come down to making the renderer (cocoon + forrest) use the correct (local or remote) catalog. fop forrest(local) forrest(remote) schema schema schema | catalog | catalog | catalog | | | | | | dtd etc. | dtd | dtd | *.dtd <-+ *.dtd <-+ *.dtd <-+ These DTDs are, I believe, set in concrete by virtue of their common PUBLID id (irrespective of the SYSTEM component of those ids, which can be completely ignored if a catalog is in place.) At this stage we are not even talking about any local extensions, are we? Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbw
Re: Getting breaks: revisited
J.Pietschmann wrote: Peter B. West wrote: ...the intention of the spec would be realised by laying out 0 of the repeatable-p-m-refs "thin", out of the available range of 0-100, then laying out 1 of the "thick" r-p-m-refs. Interesting and useful interpretation. The problem is, how to implement this? Joerg, It depends on your overall method of generating areas. This goes to overall design questions, which are on hold until we have had a chance to consider the Sun product, but if layout is driven from below (as in a sense it already is), with tentative layouts bubbling upwards until they strike an invalidating constraint, which then follows them back down the tree for a retry, and all of this eventually comes back up to the PageMaker level, then, in the case above, the result would be a no-can-do, accompanied by the dimensions of the best attempt. The PageMaker would then look for a layout master alternative, discarding the remainder of the repetitions in the process, and having a go at the "thick" master. That succeeds. If it didn't the fallback mode would be determined by the "overflow" property. 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
Keiron Liddle wrote:
The only questions I have at the moment:
- are markers handled properly, you mentioned something about that
earlier so maybe it is dealt with already
- what about arbitrary xml anywhere for extensions, is that still
possible (also instream-foreign-object but that is probably okay)
I know it is not a spec thing but it can enhance using FOP for many
users.
Marker handling is deferred until area tree construction. Not all of
the FOs that can have markers have been fitted with handling yet, but
the model for it at the FO tree building level is as follows (from
FoListBlock.java). The table-row comment, which I just noticed, is a
hang-over from another FO.
/** The number of markers on this FO. */
private int numMarkers = 0;
/** The number of list-items on this FO. */
private int numItems = 0;
/** The offset of 1st table-row within the children. */
private int firstItemOffset = -1;
while ((ev = xmlevents.expectStartElement
(FObjectNames.MARKER, XMLEvent.DISCARD_W_SPACE))
!= null) {
new FoMarker(getFOTree(), this, ev, stateFlags);
numMarkers++;
ev = xmlevents.getEndElement(xmlevents.DISCARD_EV, ev);
pool.surrenderEvent(ev);
}
There is no provision for extension elements, apart from the keeping
track of incoming elements with variant namespace declarations. In
terms of the inherent input validation of pull parsing, the checking of
foreign namespace elements could be inserted in the get/expect
processing of the FOs. The FO generation is already generalised (most
Fo? elements are nto named in the code, and are generated by the
makeFlowObject() method of FObjects, so generalising the validation of
foreign elements should be feasible. The semantics of such objects is
always going to be more of a problem.
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]
Today's the day...
Fopsters, Today (it's Thursday, my time) we hear what Tony Graham has been up to. I don't suppose anyone is in Baltimore? 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: dtd catalog (was: src/documentation/README)
Victor Mote wrote: Peter B. West wrote: I'm still floundering around here, but when I found 'catalog' in .../documentation/resources/schema, and the dtd in .../schema/dtd, I began to see a ray of light. It seems to me that such a setup should be used for all of the DOCTYPE delcarations in the documentation tree. At the moment we are relying on the system identifier component of the DOCTYPE declaration, and that is indicating a CVS retrieval - some from the xml-forrest base, some from xml-cocoon2, last time I looked. The way this works is that your validation software has to know how to find the catalog. If it does, then the catalog can contain mappings from the PUBLIC IDs in the DOCTYPE declaration to a local physical file. That setup is already in all of our documents. For example, our resources.xml file contains the following DOCTYPE: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/sche ma/dtd/document-v11.dtd"> Your catalog has to know how to map "-//APACHE//DTD Documentation V1.1//EN" to "/u/xml-schema/document-v11.dtd" or whatever your local file is. What I added several weeks ago was the URIs (yes, they are CVS-based until we find some static URI to use instead) that allow the validation to be done across the internet. This doesn't take away the ability to use a local catalog, but rather makes it no longer a necessity. My understanding is that using URIs is the preferable way to do the validation. O'Reilly's "XML in a Nutshell", 2nd edition, page 32, says "In practice, however, PUBLIC IDs aren't used very much. Almost all validators rely on the URI to actually validate the document." The only reason to use the catalog and the PUBLIC ID is if you are on a machine that doesn't have suitable net access. Norm Walsh has been campaigning for catalogs for a while now. E.g. <http://wwws.sun.com/software/xml/developers/resolver/article/>. I don't have the luxury of permanent net access. Neither do you if cvs.apache.org is down or your access to the net is cut for any reason. I think many apache developers would be in the situation that their work on open source must take place _away_ from their employment environment, and many of these would not have broadband or other permanent access. I think that factor is worth considering. 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: src/documentation/README
Christian Geisert wrote: Peter B. West wrote: You need a local forrest installation, see http://xml.apache.org/forrest/your-project.html#N10036 Christian, Thanks. I have set one up, but I was confused about automated updates. 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: src/documentation/README
Jeff Turner wrote: On Wed, Dec 11, 2002 at 11:24:34PM +1000, Peter B. West wrote: Forrestbot? Forrestbot is a glorified Ant script which automates the process of checking out a site's contents from CVS, building the docs and uploading the docs somewhere. It currently has no official role in the getting-HTML-onto-Apache process. Where? Is the login that appears at forrestbot.cocoondev.org my cvs.apache.org logname and passwd? The login transaction is not secure. forrestbot.cocoondev.org currently plays no role in the process of checking HTML into xml-site. It could in future, but not yet. The username/password is forrest-dev/forrest-dev. Logging in simply allows you to trigger a refresh of forrestbot.cocoondev.org/site/xml-fop. From the point above, this process is just like the previous one. I have a checkout on my system of xml-site/targets/fop for just this purpose. The only difference was that I would perform a cvs update of the FOP site manually, on xml.apache.org, after committing the changes. So where does forrestbot come in? It doesn't :) Sorry if I implied it did by posting that URL in the middle of the discussion. However, if no-one comes up with a better mechanism for updating the live site than xml-site/targets/*, then I will enable the commit-to-Apache-CVS button, and forrestbot.cocoondev.org will be useful as more than just a staging server. Jeff, Thanks for the clarifications. We're all stumbling towards a solution, it seems. 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: src/documentation/README
Keiron Liddle wrote: On Tue, 2002-12-10 at 19:17, Victor Mote wrote: OK, I see now that I misunderstood your "Sorry, yes" answer to Keiron. If http://forrestbot.cocoondev.org/site/xml-fop should be reflecting changes no more than an hour old made to xml-fop/src/documentation, then it is not working. I just looked for changes that were made about 24 hours ago, and they are not there. Also, as I mentioned, it shows a publish date of 12-7. So I suspect that something is not working. We have one document with a non-standard DTD (my fault, in fact that is what I am trying to work on) that might be messing up the flow. How do I go about troubleshooting this? Judging by the log it might be a DISPLAY problem. The compliance doc should only cause a broken link. Who is in charge of the cocoondev site, could they work out what the problem is? I think Sam Ruby has a script which automatically updates the live site to the contents of xml-site/targets/*. Should I contact him directly? Also, I still don't know whether xml-site/targets/fop is my final destination. What is best practices for this process? If this is documented somewhere, please excuse me -- I haven't found it yet. Also, I realize that this conversation might be better on forrest-dev. I asked on this list because I think Keiron has already figured most of this out & I am trying to leverage off of that. Thanks very much for your help. Haven't figured out all of it. There is no real documentation for the old process, currently we are only really replacing the doc generation process. Keiron, Victor, I'm still floundering around here, but when I found 'catalog' in .../documentation/resources/schema, and the dtd in .../schema/dtd, I began to see a ray of light. It seems to me that such a setup should be used for all of the DOCTYPE delcarations in the documentation tree. At the moment we are relying on the system identifier component of the DOCTYPE declaration, and that is indicating a CVS retrieval - some from the xml-forrest base, some from xml-cocoon2, last time I looked. These can (probably will) get out of sync. The dtd should be the one used when the document was last modified, shouldn't it? It seems to me there is a case for including the schema subtree, including catalog file(s) and the dtd subdirectory, in the src/build tree, and maintaining the synchronization locally. 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: src/documentation/README
Jeff Turner wrote:
Forrest is in the same boat as FOP when it comes to site updates. AFAIK,
there are no docs, but the process is:
- Committers commit generated docs to xml-site/targets/{project}
Generated by what? Forrestbot? Where? Is the login that appears at
forrestbot.cocoondev.org my cvs.apache.org logname and passwd? The
login transaction is not secure.
From the point above, this process is just like the previous one. I
have a checkout on my system of xml-site/targets/fop for just this
purpose. The only difference was that I would perform a cvs update of
the FOP site manually, on xml.apache.org, after committing the changes.
So where does forrestbot come in?
- Every X hours, a script updates /www/xml.apache.org/ or wherever on
the live site, from CVS.
Pretty messy, but this CVS-based site update system has some virtues:
- it is pull-based, so fewer security risks
- site contents can be reverted easily without an admin having to figure
out how the doc generation tool works.
- it's there and it works
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: Changes in xdocs directories
Peter B. West wrote: Keiron, Victor, I started to make some changes in the alt.design xdocs directory, and ran into problems immediately. Forrest didn't like something in one of the files, but when I went to have a look at the directory, I began to find CVS discrepancies. This morning I did a cvs update on .../src/documentation/content/xdocs/alt.design, and most of the files had gone away. Is this because of the forrest site build problems? I want to make changes to the documentation anyway, so if you let me know what the requirements are for getting the forrest site build to work, I can fix the alt.design files. If you would rather get the basics sorted out yourself, let me know. I found the image files in .../src/documentation/resources/images/design/alt.design. I'm not seeing any fop-cvs mail about these commits. Any idea why? 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]
Changes in xdocs directories
Keiron, Victor, I started to make some changes in the alt.design xdocs directory, and ran into problems immediately. Forrest didn't like something in one of the files, but when I went to have a look at the directory, I began to find CVS discrepancies. This morning I did a cvs update on .../src/documentation/content/xdocs/alt.design, and most of the files had gone away. Is this because of the forrest site build problems? I want to make changes to the documentation anyway, so if you let me know what the requirements are for getting the forrest site build to work, I can fix the alt.design files. If you would rather get the basics sorted out yourself, let me know. 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: src/documentation/README
Victor Mote wrote: Jeff Turner wrote: On Tue, Dec 10, 2002 at 10:24:28AM -0700, Victor Mote wrote: Jeff Turner wrote: See http://forrestbot.cocoondev.org/site/xml-fop Updated every hour with the latest Forrest and FOP source. I am really not yet following what is going on here. I understand the flow of files into xml-site/targets/fop. I assume that the link above is showing an hourly update of those contents (the xml-site/targets/fop is cvs, so it is getting checked out on a server somewhere). No, it is checking out xml-fop/src/documentation from CVS and building that with the latest Forrest. What you see there has no relation to what's in xml-site/targets/fop OK, I see now that I misunderstood your "Sorry, yes" answer to Keiron. If http://forrestbot.cocoondev.org/site/xml-fop should be reflecting changes no more than an hour old made to xml-fop/src/documentation, then it is not working. I just looked for changes that were made about 24 hours ago, and they are not there. Also, as I mentioned, it shows a publish date of 12-7. So I suspect that something is not working. We have one document with a non-standard DTD (my fault, in fact that is what I am trying to work on) that might be messing up the flow. How do I go about troubleshooting this? I think Sam Ruby has a script which automatically updates the live site to the contents of xml-site/targets/*. Should I contact him directly? Also, I still don't know whether xml-site/targets/fop is my final destination. What is best practices for this process? If this is documented somewhere, please excuse me -- I haven't found it yet. Also, I realize that this conversation might be better on forrest-dev. I asked on this list because I think Keiron has already figured most of this out & I am trying to leverage off of that. Thanks very much for your help. Victor, Jeff, Please keep this conversation here. I, too, am finding this process very confusing, but all of the committers need to be aware of the way the FOP web-site updates work, and we can't do that if the conversation disappears. 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
Peter B. West wrote: Keiron Liddle wrote: On Fri, 2002-12-06 at 03:47, Peter B. West wrote: 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. I don't know how much you know about it, but in HEAD Karen added whitespace handling that reduces the whitespace as it is processed (eg. when a block ends). I get about 17.5Mb for that document. I don't know what is using it all but there are lots of variables that are not being used. 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. Keiron, Using the current maint version, I made the following modifications: Forced GC for memory profiling Moved time calculation ahead of GC (it takes over 1.2 seconds) - in apps.StreamRenderer.java Commented out the call to render() Allowed page-sequence FO subtree to be added to the FO tree - in fo.FOTreeBuilder.java Compiled and run under j2sdk-1.4.1 and build.compiler=jikes. Obviously all of the renderer setup code is still present, including font setup, and as you say, there are no doubt variables which are initialised for the rendering. Results (fastest of three successive runs): [DEBUG] Input mode: [DEBUG] FO [DEBUG] fo input file: /home/pbw/public_html/xml/real-life-51-page-document.fo [DEBUG] Output mode: [DEBUG] pdf [DEBUG] output file: /tmp/51.pdf [DEBUG] OPTIONS [DEBUG] no user configuration file is used [default] [DEBUG] debug mode on [DEBUG] dump configuration [DEBUG] quiet mode on [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] base directory: file:/home/pbw/public_html/xml/ [INFO] FOP 0.20.5cvs [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [INFO] Parsing of document complete, stopping renderer [DEBUG] Total time used: 17159ms [DEBUG] Pages rendered: 0 [DEBUG] Initial heap size: 497Kb [DEBUG] Current heap size: 16922Kb [DEBUG] Total memory used: 16425Kb The equivalent figures from my original post are: Initial heap size: 352Kb Current heap size: 8879Kb Total memory used: 8527Kb The comparable time is the elapsed time before preorder scan: 15960ms Fop-devs, I have just run some quick test of property generation, to determine whether I was actually generating the property sets for the FOs. Although there are obviously still some bugs in property generation, the full property sets are being generated. I don't think that almost halving the memory usage of the FO tree build can be accounted for by "unused variables" in the maint code. Rather, it seems that the rewrite of FO tree building and property representation has achieved its design goal: significantly reduced memory usage. To my surprise, it also runs faster, in spite of using an admittedly less efficient pull parsing method implemented over the top of SAX. Taking advantage of native pull parsing APIs when they become available (and the Neko pull parser is slated for release with Xerces soon) will increase the performance. Now if I can work out Forrest, I'll update the documentation. 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: I still believe that it is useful to have the layout managers separate from the fo tree. There are a number of reasons that come to mind. It is possible to independantly change layout managers. Certain fo's aren't directly in the same hierarchy: markers, undefined table columns, table cells under table body. Then there are things like floats and footnotes that can gain from this. Keiron, I'm inclining in this direction myself, because I am interested in isolating the layout/area tree functions as much as possible from the raw information stream of the FO tree. I tend to view the FO tree as a read-only data source for the layout. manaaged by the Fo objects. 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: Getting breaks: revisited
J.Pietschmann wrote: Victor Mote wrote: Just to be clear, I should point out that there is not a layout that is impossible to perform. There are layouts for which it is very hard to decide what to do. Consider the following: http://www.w3.org/1999/XSL/Format";> blabla.. Should this create 100 empty pages and render the text onto the 101st page, or should it squeeze it onto the first page, thereby violating the advised width constraint of the block? The user could have either in mind. Joerg, I kept this one in my inbox, and have finally got back to it. I would have thought that in a case like this, the intention of the spec would be realised by laying out 0 of the repeatable-p-m-refs "thin", out of the available range of 0-100, then laying out 1 of the "thick" r-p-m-refs. This would work in the same way for the other case you mention - constrained height and keep-together table rows. 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
Arved Sandstrom wrote: I actually helped push for this last year - the notion of separate layout managers. I was strongly influenced by the mess that FOP code had become at the time, and really thought that layout should be taken out of the FOs themselves; that the FO's, in a sense, were (or should be) just value objects. I worked on an xslfo-proc prototype (in Perl) for months earlier this year. I started out with the layout manager idea. It became increasingly clear to me that there was in fact a natural 1-1 correspondence between managers and FOs. I had a prototype, incidentally, which properly handled reference-orientation in all regions, and even took RO down to block-containers, something which no implementation (not FOP, not XEP, not XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, which I don't know. It's also interesting, Joerg, that you should mention a "hard to understand" layout manager class hierarchy...this is also what inevitably developed in my prototype. So at some point (and I think there are comments and emails to support this) I eventually came back to the thought that there is nothing wrong with individual FOs being able to do their own layout. Which is actually the existing "maintenance stream" FOP model. Here are a couple. I remembered these exchanges, and was wondering whether you might mention them in this context. http://sourceforge.net/mailarchive/forum.php?thread_id=740835&forum_id=450 http://sourceforge.net/mailarchive/message.php?msg_id=1780417 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: fop.xsd
Peter B. West wrote: Victor, I'm not sure what your intention is, but from the wording of the commit comment, I think I may have mislead you with a previous posting. 4f was the superseded version. (Yes, I know, I should have left 4g.) fop4.xsd contained the latest version (4g). Victor, Sorry about the premature response. 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]
fop.xsd
Victor, I noticed from your commt that the 'country-name's had lost their spaces, e.g., MACEDONIA,THEFORMERYUGOSLAVREPUBLICOF. I don't know whether this was in the original, but it certainly reads awkwardly. fop.xsd also includes 2-letter language codes. However, the 3-letter language codes are the ones we need. They have terminology and bibliographic variants (the terminology variant is normative for XSL) which occasionally differ. Many languages have the legacy 639-1 2-letter as well, and it is useful to keep them about the place, as they are frequently used, e.g. en_US. See ISO 639-2T, ISO 639-2B, ISO 639-1 <http://www.loc.gov/standards/iso639-2/> In conf/xml-lang.xml (under tag FOP_0-20-0_Alt-Design, naturally) I have included these variants as optional attributes in the language entries. E.g. the following consecutive entries: EnglishName="Chinese" FrenchName="chinois"/> EnglishName="Chuukese" FrenchName="chuuk"/> fop.xsd has no "script" entries. xml-lang.xml contains script codes according to the latest version of the ISO 15924 draft that I could find. Chuck, if you want me to post a copy of the file to you, let me know. 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]
fop.xsd
Victor, I'm not sure what your intention is, but from the wording of the commit comment, I think I may have mislead you with a previous posting. 4f was the superseded version. (Yes, I know, I should have left 4g.) fop4.xsd contained the latest version (4g). 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
Keiron Liddle wrote: On Fri, 2002-12-06 at 03:47, Peter B. West wrote: 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. I don't know how much you know about it, but in HEAD Karen added whitespace handling that reduces the whitespace as it is processed (eg. when a block ends). I get about 17.5Mb for that document. I don't know what is using it all but there are lots of variables that are not being used. 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. Keiron, Using the current maint version, I made the following modifications: Forced GC for memory profiling Moved time calculation ahead of GC (it takes over 1.2 seconds) - in apps.StreamRenderer.java Commented out the call to render() Allowed page-sequence FO subtree to be added to the FO tree - in fo.FOTreeBuilder.java Compiled and run under j2sdk-1.4.1 and build.compiler=jikes. Obviously all of the renderer setup code is still present, including font setup, and as you say, there are no doubt variables which are initialised for the rendering. Results (fastest of three successive runs): [DEBUG] Input mode: [DEBUG] FO [DEBUG] fo input file: /home/pbw/public_html/xml/real-life-51-page-document.fo [DEBUG] Output mode: [DEBUG] pdf [DEBUG] output file: /tmp/51.pdf [DEBUG] OPTIONS [DEBUG] no user configuration file is used [default] [DEBUG] debug mode on [DEBUG] dump configuration [DEBUG] quiet mode on [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] base directory: file:/home/pbw/public_html/xml/ [INFO] FOP 0.20.5cvs [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [INFO] Parsing of document complete, stopping renderer [DEBUG] Total time used: 17159ms [DEBUG] Pages rendered: 0 [DEBUG] Initial heap size: 497Kb [DEBUG] Current heap size: 16922Kb [DEBUG] Total memory used: 16425Kb The equivalent figures from my original post are: Initial heap size: 352Kb Current heap size: 8879Kb Total memory used: 8527Kb The comparable time is the elapsed time before preorder scan: 15960ms 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 Aultman wrote: 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? Rhett, Please do. 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: 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: 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
, 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 darwinism" described by Bertrand to function for FOP, both alternative streams would need to have a bigger developer community to move them along and to explain their merits. Do we have the human resources to afford that? And do we want to do that? If not, how do we decide how to make a better FO processor. These are the questions we had better discuss, the sooner the better. 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]
Redesign issues
Arved Sandstrom wrote: You're being absolutely honest, which is cool - I'll be absolutely honest also. It seems to me like the mainstream rewrite is in trouble. Very few people understand it or have [clearly] bought into it. This is no comment on its technical merits, by any means. OTOH, only one person has been working on the alternative - you yourself, Peter. So what we really have is 3 projects: maintenance, rewrite, and alternative, and most of the committers and developers seem to be working on maintenance. Correct me if I'm wrong. In a sense, we have four. Although xslfo-proc is being developed in another place and language, you are still very much a part of this development community, active of not. I nominate xslfo-proc as the fourth project because, to the best of my knowledge, you and Eric are taking a different approach to design again. And the design, as you point out, is the critical issue. Whatever success you have with design in xslfo-proc should be of great interest here. The problems you describe in your email are symptoms, in my opinion. Forrest is irrelevant...we have bigger problems. In fact, pull vs push vs tree is also irrelevant, because that is dancing around the big issues - understanding the FO spec, and being able to implement it. Has anyone so far, for example, described a clear vision for properly handling keeps? A comprehensive vision, no. But what I consider to be some necessary elements of the solution, yes. And I firmly believe that the problem is comprehensively solvable. No, they haven't. Does anyone here think the FO problem is non-deterministic? Raise your hands, please. :-) No? In which case, why (years after this project started) do we not have clear algorithms stating exactly what we will do in various situations? 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. My impression though (and I am happy to have my ignorance corrected on this) is that the redesign is being attempted piecemeal, without a broad overview. If I am correct in this, it would be largely explained by the complexity of the problem, and the determination to retain as much as possible of the existing code base, and therefore, of the existing design. If I am wrong in this, it may be symptomatic of, in addition to my laziness and obtuseness, inadequate top-level documentation (including diagramming) of the way the layout is attacked. Whether or not those considerations actually apply in this case, if you are using piecemeal design as a way to attack complexity, you must be prepared to throw things away when they prove not to be fruitful, as many things inevitably will. I could care less at this point about SAX and DOM and pull and push - that's XML processing. Our FO processing algorithms, stated in design notes, should express independently of XML processing model how we will handle every FO situation. I agree with you here. By the time the layout is triggered in the current model, the relevant part of the FO tree has been built, so the layout engine is always working on a complete subtree. However, it seems to me that the existing design, and possibly the redesign, do not take full advantage of this. The alt.design has the advantage of being based on an explicit, fully navigable tree structure. However, that structure is not, in itself, sufficient to express the relationships needed for layout. We have had discussions in the past about tree vs. flat structures for the area tree. I believe that both views are needed simultaneously, and that the "flat" view can be obtained by running "threads" of links through the tree to represent page-contiguous elements for the resolution of keeps and space-specifiers, for example. I am not dismissing your concerns, Peter. I just think that we've got bigger ones. We are the committers; we need to decide once and for all what we intend to do. If it assuages your feelings any, I happen to be partial to your pull model - I am personally very comfortable with SAX, but I recognise that most are not. 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: FOP schema
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-dev&m=103547432006815&w=4 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 info
sri vela wrote: Hi all, I would like to know about fop alt.design. Where can i find the documentation for this? will it change the entire old design ro part of it? What should i do to involve in alt.design. Thanks in advance. Sri, Sorry I wasn't able to get back to you earlier. There is a new round of discussions about design getting underway now, after which the direction of design work may be more clear, including the way such thorny issues as "auto" table layout are to be dealt with. As things stand, the "New design" effort is much more mature, and is actually performing useful layout. The layout component of alt.design is, as yet, only a few design notes, to which Oleg has pointed you. These will be updated shortly to reflect the actual FO tree and properties design which has largely been completed. Please read the notes and give me your feedback. Befoer becoming committed to any particular line of development, however, read the discussion here about the design direction. 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
Oleg Tkachenko wrote: 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? Yes. 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. It would be interesting. 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]
Alt-Design: Preliminary results FO tree build test
Fop-devs, Herewith the preliminary results of running the alt.design FO tree build against the 51 page test document supplied by Bertrand. 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 Memory figures after a final GC, besides being somewhat confusing, are Total memory after GC : 16334848 Free memory after GC: 7242184 The command was: time java $Fop -fo /home/pbw/public_html/xml/real-life-51-page-document.fo The full output from the test run follows. userConfigFileName reading user configuration file userconfig.xml Can't find user configuration file userconfig.xml in user locations base directory: file:/home/pbw/public_html/xml/ Version: FOP 0.20.0 Alt-Design Input mode: fo fo input file: /home/pbw/public_html/xml/real-life-51-page-document.fo Output mode: pdf output file: /usr/local/src/xml-fop_20_Alt/docs/examples/tests/test.pdf OPTIONS user configuration file: userconfig.xml debug mode on don't dump configuration [default] low level areas generated[default] quiet mode off [default] FOP Developers Build using SAX parser org.apache.xerces.parsers.SAXParser Starting parserThread parserThread started foThread started simple-page-master ok simple-page-master ok simple-page-master ok Making sparsePropsSet for static-content. Making sparsePropsSet for flow. Making sparsePropsSet for static-content. Making sparsePropsSet for static-content. Making sparsePropsSet for flow. Size of event pool: 74 Next event id : 78 Back from buildFoTree Elapsed time: 15960 # of FONodes: 11044 Back from driver.run() Elapsed time: 16176 Total memory before run : 2031616 Total memory after run : 11886592 Total memory after GC : 16334848 Diff before/after total : 9854976 Diff before/GC total: 14303232 Diff after/GC total : 4448256 Free memory before run : 1670696 Free memory after run : 2114040 Free memory after GC: 7242184 Diff before/after free : 443344 Diff before/GC free : 5571488 Diff after/GC free : 5128144 cg() freed : 5128144 18.02s real11.71s user 0.24s system 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]
