[GUMP@brutus]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-08122004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-08122004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-08122004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-08122004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-08122004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-08122004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-08122004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - junit: [javac] Compiling 31 source files to /home/gump/workspaces2/public/workspace/xml-fop/build/test-classes [javac] This version of java does not support the classic compiler; upgrading to modern [javac]
Retrieve-marker and removal of leading and trailing spaces
Hi, I also noted a problem with the removal of leading and trailing spaces in connection with retrieve-marker: fo:static-content flow-name=xsl-region-after fo:block text-align=start fo:inline color=redfo:retrieve-marker retrieve-class-name=class retrieve-boundary=page retrieve-position=first-starting-within-page//fo:inline and blue: fo:inline color=bluefo:retrieve-marker retrieve-class-name=class retrieve-boundary=page retrieve-position=first-starting-within-page//fo:inline /fo:block /fo:static-content The spaces before `and' and after `blue:' are removed. This is probably due to the fact that the space removal mechanism does not recognize that fo:retrieve-marker elements may generate text. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Another problem with Marker.rebind()
I noticed another problem with Marker.rebind(): When the same marker is retrieved more than once, the first rebind is overwritten with the second. See this example: fo:static-content flow-name=xsl-region-after fo:block text-align=start fo:inline color=redred: fo:retrieve-marker retrieve-class-name=class retrieve-boundary=page retrieve-position=first-starting-within-page//fo:inline, fo:inline color=blueblue: fo:retrieve-marker retrieve-class-name=class retrieve-boundary=page retrieve-position=first-starting-within-page/./fo:inline /fo:block /fo:static-content Both markers are printed in blue. Perhaps it would be a solution to clone the subtree below the marker to retrieve-marker, and rebind that copy. That would be another example of layout dependent data in the FO tree. If every retrieve-marker would always discard its existing subtree and copy the subtree under the retrieved marker in LM.preloadnext(), this would prevent later runs with the same FO tree from reusing markers that would pertain to the layout of an earlier run. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Retrieve-marker and removal of leading and trailing spaces
Simon Pepping wrote: The spaces before `and' and after `blue:' are removed. This is probably due to the fact that the space removal mechanism does not recognize that fo:retrieve-marker elements may generate text. Whitespace/linefeed handling should run after rebinding the retrieved marker content in order to get it right. I personally still think it should be integrated into break position computation, with something like a whitespace state held in the layout context. J.Pietschmann
RE: Another problem with Marker.rebind()
Simon Pepping wrote: Both markers are printed in blue. Perhaps it would be a solution to clone the subtree below the marker to retrieve-marker, and rebind that copy. That would be another example of layout dependent data in the FO tree. If every Just by way of clarification, this is no doubt de facto true in the current FOP HEAD code, but, depending on the design, IMO it is not a necessity. Peter West and I discussed this some, probably around August of 2003. I thought at the time that a GraftingPoint interface which lived in the FOTree could be used to handle this concept without disrupting the independence of the FOTree. I am now of the opinion that the solution may be even simpler. If you take the idea that the AreaTree is a view of the FOTree, so that Areas essentially inherit and/or derive traits from their generated-by FOTree nodes (instead of having bound values cached in them), then the solution may be as simple as using some redirects when static content is involved. This depends, in turn, on late binding (really, no binding) of the property values, which does not appear to be possible with the current FOP design. I am close to being able to demonstrate all of this within FOray, but I am not sure whether I will get it done in time for the upcoming 0.2 release, although it will have an independent FOTree. Victor Mote
Re: Another problem with Marker.rebind()
Victor Mote wrote: Simon Pepping wrote: Both markers are printed in blue. Perhaps it would be a solution to clone the subtree below the marker to retrieve-marker, and rebind that copy. That would be another example of layout dependent data in the FO tree. If every There is a certain wry entertainment value in watching the wheel being re-invented. Before I arrived, this problem was known as re-parenting. In my discussions of the issue, years after re-parenting was first discussed, there is even a diagram - shock, horror! - of the basic process proposed for Defoe (then the non-longer visible, but still present, Alt-design). Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. It does render the marker problem trivial, but so what. We have HEAD. Finn's off scratching his head vigorously, having just realized that there is a fundamental flaw in the design wrt markers. It will be interesting to see what emerges. Just by way of clarification, this is no doubt de facto true in the current FOP HEAD code, but, depending on the design, IMO it is not a necessity. Peter West and I discussed this some, probably around August of 2003. I thought at the time that a GraftingPoint interface which lived in the FOTree could be used to handle this concept without disrupting the independence of the FOTree. I am now of the opinion that the solution may be even simpler. Couldn't agree more, Victor. If you take the idea that the AreaTree is a view of the FOTree, so that Areas essentially inherit and/or derive traits from their generated-by FOTree nodes (instead of having bound values cached in them), You can combine both ideas. then the solution may be as simple as using some redirects when static content is involved. Bingo! This depends, in turn, on late binding (really, no binding) of the property values, ...and again... which does not appear to be possible with the current FOP design. ...and again. I am close to being able to demonstrate all of this within FOray, but I am not sure whether I will get it done in time for the upcoming 0.2 release, although it will have an independent FOTree. Thanks for pointing all of this out, Victor. It's nice to see some convergence on these ideas. Interesting that it must happen in Defoe and Foray. Peter
Re: Another problem with Marker.rebind()
- Original Message - From: Peter B. West [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 8:20 PM Subject: Re: Another problem with Marker.rebind() Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. Peter, are you saying that a pull parser is more computationally powerful than a SAX Parser--or is it just much more convenient? I don't think pull parsers can do more than SAX Parsers for the simple reason that you can implement a pull parser using a SAX Parser, no? Glen
Re: Another problem with Marker.rebind()
Glen Mazza wrote: Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. Peter, are you saying that a pull parser is more computationally powerful than a SAX Parser--or is it just much more convenient? I don't think pull parsers can do more than SAX Parsers for the simple reason that you can implement a pull parser using a SAX Parser, no? Firstly, my apologies to all for the tone of my previous message. Too little sleep, too much gall. Defoe uses SAX for its stream parsing. Consequently, it's less computationally efficient. To use an extreme example, for many years compilers were less computationally efficient than coding with assembler. There are inefficiencies at every level of a computer system, from the microcode up. At any level, does the interface ease the development of solutions built on top? For most of my initial stint at FOP, I was obsessively concerned with micro-efficiencies, and I displayed my ignorance concerning this on many occasions. (Ask Jeremias or Joerg.) I have watched improvements in the performance of JVMs overtake my obsessions while I have been working on FOP. So much for not teaching an old dog new tricks. In spite of those concerns, I went with an inefficient parsing mechanism, because it mightily clarified the parsing process. As a completely unintentional side-effect, it gave me the tools to solve the really critical FOP performance problem on large files. This isn't going to be solved by micro-efficiencies on FO tree storage. Unfortunately, software developers are an intensely conservative lot. R J Neuhaus has a lovely term, the herd of independent minds. And he's not even describing software developers. It will be a long time before the SAX franchise falters. The curious thing is that Microsoft never went down the SAX road. They get by. Defoe is a big job, and I need all the help I can get, but I'll get there. Peter
AW: Embedding XMP in FO
Hi Jeremias, you haven't told us what branch you are on. Are you on the maintenance branch or on FOP HEAD? I suppose I'm working with the 0.20.5 code base... These hints are targeted at FOP HEAD code but some can be applied to the maintenance branch, too, although the whole mechanism is quite different there. I didn't had the chance to look at the HEAD branch yet. Is it in an stable/usable state? One thing you will have to do is creating an ElementMapping class (plus node subclasses, or you extend the existing ExtensionElementMapping) so the FOTreeBuilder can create nodes for each XML element of the various namespaces in the metadata part. A good example in your case is the bookmarks support code you can find in the org.apache.fop.fo.extensions package. There you have an example of an ElementMapping class (ExtensionElementMapping) and node classes (Bookmarks/Outline). That's the first step. I tried to build up a separated DOM with the XMP data in it (similarly to the SVG stuff). But I think there are several restrictions so that I doubt that this could be done with the 0.20.5 sources. Examples: 1) There is no way to define an own PropertyHandler. There are two for FO and SVG, but they are in the fop.jar as class files. 2) The SAX parser does not submit the prefix bindings for namespaces (e.g. xmlns:xap=http://ns.adobe.com...;) as attributes. They are missing in the PropertyList. 3) Leaf text nodes are not submitted to FObj.addCharacters(...). I'm not sure if attaching the metadata to a page-sequence is the right approach. The page-sequence itself isn't represented in the resulting PDF. You might also have multiple page-sequences in a document. So you should probably attach it to fo:root where it applies to the whole document. Attaching metadata to individual pages or objects is probably trickier. Yes, you're right. Attaching it to the 'root' and to a 'block' or 'foreign-instream-object' is sounder. This should give you a few pointers into the code. I'm not sure if I got everything right, because I'm not so familiar with this part, yet. Hopefully, my colleagues will correct me if I wrote anything wrong. Thanks, it helped me out. But I don't think that the 0.20.5 sources will get me any further... Btw: Did you notice that it does not compile if you remove the fop.jar with compiled sources from the classpath? There seem to be inconsistent packages between the fop.jar and the actual source directory tree. I hope this helps nonetheless. We're looking forward to your patches for FOP HEAD. ;) Well, we'll see :-). One request: Please do not see SVG as the *only* foreign XML vocabulary that one could embed in FO :-). Thank you, Victor
