*****SPAM***** Re: Building FOP Trunk with Any - BUILD FAILED
Spam detection software, running on the system poa.cs.unibo.it, has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Ok, I wanted to test this at home to see if this was a machine issue. Tested on: Windows XP sp2 Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b12) Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode, sharing) [...] Content analysis details: (4.3 points, 4.0 required) pts rule name description -- -- 0.7 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/why.html?sender=fop-dev-return-35246-laera%3Dcs.unibo.it%40xmlgraphics.apache.orgip=130.136.10.101receiver=poa.cs.unibo.it] 2.3 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers -0.2 BAYES_40 BODY: Bayesian spam probability is 20 to 40% [score: 0.3371] 1.5 WHOIS_MYPRIVREGURL registered to myprivateregistration.com [URIs: nabble.com] ---BeginMessage--- Ok, I wanted to test this at home to see if this was a machine issue. Tested on: Windows XP sp2 Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b12) Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode, sharing) I am still unable to build with ant. I get another set of errors. I will email Jeremias the out.txt file. I also tried the the version (src/java/org/apache/fop/events/model/EventModel.java) posted, but got a bunch of errors. I will send that report to. Bones Jeremias Maerki-2 wrote: On 12.07.2008 11:56:23 Andreas Delmelle wrote: On Jul 11, 2008, at 13:22, Jeremias Maerki wrote: Bonekrusher and I had an exchange off-list. He did a few tests for me and my recent change didn't help either. Basically, we established the following: - He's also running WinXP - He's running the same JDK as I do. The /exact/ same one (identical build)? Yes, Sun 1.6.0_04 Just asking, since I remember running across some issues/ inconsistencies in the way the java.net.URL and java.net.URI translate themselves to a String. Maybe that's what's playing here... Is the warning about the deprecated File.toURL() maybe related and a hint? If it is in fact the file URL that's the problem, I'm pretty sure the problem happens within Xalan as I'm passing in a StreamResult(File). As of Java 6, the recommended way is to use File.toURI().toURL(). According to the API docs, File.toURL() does not automatically escape characters that are illegal in URLs. It is recommended that new code convert an abstract pathname into a URL by first converting it into a URI, via the toURI method, and then converting the URI into a URL via the URI.toURL method. I guess it makes sense to change all occurences now that we're on Java 1.4. I've changed the StreamSource(File) to StreamSource(File.toURI().toURL().toExternalForm()) as a first experiment. Bonekrusher can then retry on his machine. http://svn.apache.org/viewvc?rev=676161view=rev On my machine the following: System.out.println(outputFile.toURI().toASCIIString()); System.out.println(outputFile.toURI().toString()); System.out.println(outputFile.toURI().toURL().toExternalForm()); System.out.println(outputFile.toURL().toExternalForm()); yielded the following results: [eventResourceGenerator] file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml [eventResourceGenerator] file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml [eventResourceGenerator] file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml [eventResourceGenerator] file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml Just for reference, Bonekrusher got file:\C:\fop_trunk\trunk\build\gensrc\org\apache\fop\events\event-model.xml on his machine (see his first post). Makes you wonder why the implementation of toURL() then does not simply do that already... I assume this is for reasons of backward- compatibility, so as to not break any existing code that relies on that behavior (?) Probably. Cheers Andreas Jeremias Maerki -- View this message in context: http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18428400.html Sent from the FOP - Dev mailing list archive at Nabble.com. ---End Message---
Re: Building FOP Trunk with Any - BUILD FAILED
Bones wrote: In the end, I got it working by making sure that the build process was using the exact same XML parser and XSLT processor that were distributed with FOP. - How do I do that with in ant? You're doing it. It's controlled by the classpath set up by ant, which looks pretty straightforward. All the jars in lib and lib/build + the codegen classes. So something very odd is going on. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Support for XSL-FO 1.1 formatting objects for indexing
This is my first post. We've been using Apache FOP quite successfully for the past year or so, converting XML for technical manuals to PDF. The one feature that we're anxious to see is indexing support (XSL-FO 1.1, 6.10). Does anyone know if this is being worked on? Thanks, Dave Siemens -- View this message in context: http://www.nabble.com/Support-for-XSL-FO-1.1-formatting-objects-for-indexing-tp18488727p18488727.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Support for XSL-FO 1.1 formatting objects for indexing
Dave of Siemens wrote: This is my first post. We've been using Apache FOP quite successfully for the past year or so, converting XML for technical manuals to PDF. The one feature that we're anxious to see is indexing support (XSL-FO 1.1, 6.10). Does anyone know if this is being worked on? Not that I know of. It would indeed be a great addition to FOP. Patches are always most welcome :) Thanks, Chris
Re: Support for XSL-FO 1.1 formatting objects for indexing
On Jul 16, 2008, at 18:45, Chris Bowditch wrote: Dave of Siemens wrote: This is my first post. We've been using Apache FOP quite successfully for the past year or so, converting XML for technical manuals to PDF. The one feature that we're anxious to see is indexing support (XSL-FO 1.1, 6.10). Does anyone know if this is being worked on? Not that I know of. It would indeed be a great addition to FOP. Patches are always most welcome :) Well, I thought about it a few months ago, and IIJC, this is one of those features that requires a good understanding of the entire FOP processing-cycle. It requires modifications in all the major subsystems (FO Tree/Properties, Layout and Rendering), so I wouldn't really advise it as something to get his/her feet wet (unless you don't mind diving in the deep end ;-)) I know of one other user who has explicitly asked for this (Gerhard Oettl), and this was quite some time ago... It's unfortunately not something that keeps popping up in questions, so not really high on the priority list, but I very much agree that it would be a really fine addition. Personally, I probably will not have time to look closer at it very soon, but I'll see if I can publish some of the ideas I gathered on a Wiki page, for future reference. Cheers Andreas
Re: Building FOP Trunk with Any - BUILD FAILED
On Jul 16, 2008, at 13:00, Bones wrote: Hi Phil My parser/transform environment is the standard which comes with FOP, however when I use FOP for development I also use SAXON for transformation and sometimes pure Sax2 for parsing. It depends. I haven't yet encountered such issues when /running/ FOP, only when building. If you only use FOP, this shouldn't really pose a problem. Seen that you're eager to start developing, it is a rather unfortunate one... :-/ BTW: Remember also that, when running FOP, unless you explicitly force the JVM to use the Xerces and Xalan versions in the distribution, then it will use whatever XML parser and XSLT processor come first in the classpath (most JVMs come bundled with a fallback parser; some, like GNU Classpath, do not have an XSLT processor, which causes mayhem in some environments because Xalan does not work in combination with the GNU XML parser...) In the end, I got it working by making sure that the build process was using the exact same XML parser and XSLT processor that were distributed with FOP. - How do I do that with in ant? Basically the same as for every other java application, it comes down to either: * copying all necessary JARs to JAVA_HOME/lib/endorsed * prepending those JARs to the bootclasspath (as in: java - Xbootclasspath/p:...) * specifying the exact implementations to use by passing Java system properties (pattern: -Dinterface=implementation, as in: java - Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryI mpl ...) The latter two options, for Ant, work by setting the ANT_OPTS environment variable (see: http://ant.apache.org/manual/ running.html#envvars) The first I already hinted at earlier, and you said you had tried it, to no avail, so I'm quite clueless at the moment. :-S Cheers Andreas
Re: Building FOP Trunk with Any - BUILD FAILED
On Jul 16, 2008, at 20:41, Bones wrote: Well, I am too. My advise is to put this issue on the the back burner and see if anyone can duplicate the problem. thoughts? Always... :-) If all else fails, I guess we could always send you the pre-generated files, see if that gets you up and running (?) It just seems that somewhere, /some/ component decides on using file.separator instead of a simple forward slash, which mucks up the URL. Run 'ant -diagnostics resourcegen' and post (or mail me) the results. Maybe that gives us a clue. Thanks, Andreas
Re: Building FOP Trunk with Any - BUILD FAILED
I got lucky!! I didn't really work on this just now but I activated one of my other FOP working copy and had the error Phil reported: C:\Dev\FOP\main\xml-fop-temp\build.xml:353: java.io.IOException: java.io.FileNotFoundException: file:\C:\Dev\FOP\main\xml-fop-temp\build\gensrc\org\apache\fop\events\event-model.xml (The filename, directory name, or volume label syntax is incorrect) I added some test code in EventModel and look what I got: resourcegen: [eventResourceGenerator] file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml [eventResourceGenerator] file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml [eventResourceGenerator] file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml [eventResourceGenerator] Apache Xalan: Xalan Java 2.4.1 [eventResourceGenerator] org.apache.xalan.processor.TransformerFactoryImpl So my code is actually passing in the right file URL but Xalan messes it up internally somewhere. Please note that I reproduced this with Sun Java 1.4.2_16, not 6.0.something. Once I put the XML libraries from FOP's lib directory in the JDK's jre/lib/endorsed directory, Xalan showed version 2.7.0 and the build ran through. I wonder why I didn't run into this sooner. I always build FOP with FOP 1.4.2_16 with no endorsed directory. Weird stuff. And I'm absolutely clueless why this bug was triggered in Phil's environment as he uses Java 6 which uses a newer Xalan. Anyway, I've just committed a work-around that avoids passing the XSLT processor the target file URL and instead works with OutputStreams I manage myself. http://svn.apache.org/viewvc?rev=677404view=rev Phil, please do another svn up and retry. I hope this is it this time. On 16.07.2008 20:41:12 Bones wrote: Well, I am too. My advise is to put this issue on the the back burner and see if anyone can duplicate the problem. thoughts? Andreas Delmelle-2 wrote: On Jul 16, 2008, at 13:00, Bones wrote: Hi Phil My parser/transform environment is the standard which comes with FOP, however when I use FOP for development I also use SAXON for transformation and sometimes pure Sax2 for parsing. It depends. I haven't yet encountered such issues when /running/ FOP, only when building. If you only use FOP, this shouldn't really pose a problem. Seen that you're eager to start developing, it is a rather unfortunate one... :-/ BTW: Remember also that, when running FOP, unless you explicitly force the JVM to use the Xerces and Xalan versions in the distribution, then it will use whatever XML parser and XSLT processor come first in the classpath (most JVMs come bundled with a fallback parser; some, like GNU Classpath, do not have an XSLT processor, which causes mayhem in some environments because Xalan does not work in combination with the GNU XML parser...) In the end, I got it working by making sure that the build process was using the exact same XML parser and XSLT processor that were distributed with FOP. - How do I do that with in ant? Basically the same as for every other java application, it comes down to either: * copying all necessary JARs to JAVA_HOME/lib/endorsed * prepending those JARs to the bootclasspath (as in: java - Xbootclasspath/p:...) * specifying the exact implementations to use by passing Java system properties (pattern: -Dinterface=implementation, as in: java - Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryI mpl ...) The latter two options, for Ant, work by setting the ANT_OPTS environment variable (see: http://ant.apache.org/manual/ running.html#envvars) The first I already hinted at earlier, and you said you had tried it, to no avail, so I'm quite clueless at the moment. :-S Cheers Andreas -- View this message in context: http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18493995.html Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
Re: Building FOP Trunk with Any - BUILD FAILED
Peter B. West wrote: Bones wrote: In the end, I got it working by making sure that the build process was using the exact same XML parser and XSLT processor that were distributed with FOP. - How do I do that with in ant? You're doing it. It's controlled by the classpath set up by ant, which looks pretty straightforward. All the jars in lib and lib/build + the codegen classes. So something very odd is going on. D'uh -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
On Jul 16, 2008, at 22:21, Jeremias Maerki wrote: I got lucky!! I didn't really work on this just now but I activated one of my other FOP working copy and had the error Phil reported: snip / I wonder why I didn't run into this sooner. I always build FOP with FOP 1.4.2_16 with no endorsed directory. Weird stuff. And I'm absolutely clueless why this bug was triggered in Phil's environment as he uses Java 6 which uses a newer Xalan. Since the error is restricted to Windows, let's blame Microsoft. ;-P (I guess there's even a possibility that Xalan does not actually do anything wrong, but also calls File.toURL() somewhere, and the JVM's native implementation makes use of some Windows API function, which is responsible for the invalid URL...) Anyway, I've just committed a work-around that avoids passing the XSLT processor the target file URL and instead works with OutputStreams I manage myself. http://svn.apache.org/viewvc?rev=677404view=rev Yay!! Was I missing the obvious? Indeed, why even convert the File to a URL, if StreamSource() accepts, well, an InputStream, which bypasses this strangeness altogether... :-) Cheers Andreas
