RE: FOP Performance
Hi again! The Performance problem figured out to be a problem in using SVG images as Backgorund images for the xsl-region-before/after/start/end. Any ideas on how to fix this problem without changing to another picture format. (jpg and gif do look bad imho) Thanks and best regards, Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP Performance
I'm not very fit in all this technical stuff. Do you know any kind of documentation etc. which could help me keeping FOP in memory? Best Regards, Christian -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, November 11, 2005 11:26 AM To: fop-users@xmlgraphics.apache.org Subject: Re: FOP Performance Batik takes a long time to warm up due to its size (class loading). If you use the servlet approach, i.e. having FOP up, running and ready the whole time, it will speed up the process a lot. If you find another way to hold FOP and the VM it runs in memory over multiple rendering runs(some PHP extension, a web service or whatever), that's fine, too. Most of the time is simply lost with class loading and initialization. HTH. On 11.11.2005 10:59:45 Christian Loock wrote: Hi again! The Performance problem figured out to be a problem in using SVG images as Backgorund images for the xsl-region-before/after/start/end. Any ideas on how to fix this problem without changing to another picture format. (jpg and gif do look bad imho) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP Performance
http://xmlgraphics.apache.org/fop/0.20.5/servlets.html Basically you need to: - build the sample FOP servlet as described on the above page - Download Apache Tomcat and install it as a service - Deploy FOP in Tomcat as described on the above page I know almost nothing about PHP so I wouldn't know about any better approaches to this from the PHP point of view. Maybe you can Michael Dabney to publish the details of his solution using the PHP Java Bridge on the FOP Wiki [1] under the HowTo section. His approach sounds pretty good, too. [1] http://wiki.apache.org/xmlgraphics-fop/ On 11.11.2005 11:50:23 Christian Loock wrote: I'm not very fit in all this technical stuff. Do you know any kind of documentation etc. which could help me keeping FOP in memory? Best Regards, Christian -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, November 11, 2005 11:26 AM To: fop-users@xmlgraphics.apache.org Subject: Re: FOP Performance Batik takes a long time to warm up due to its size (class loading). If you use the servlet approach, i.e. having FOP up, running and ready the whole time, it will speed up the process a lot. If you find another way to hold FOP and the VM it runs in memory over multiple rendering runs(some PHP extension, a web service or whatever), that's fine, too. Most of the time is simply lost with class loading and initialization. HTH. On 11.11.2005 10:59:45 Christian Loock wrote: Hi again! The Performance problem figured out to be a problem in using SVG images as Backgorund images for the xsl-region-before/after/start/end. Any ideas on how to fix this problem without changing to another picture format. (jpg and gif do look bad imho) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Next Stable Version
Hi Everybody, I'm writing again to ask if there are any predictions when the new version of fop will be released. Best regards, Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Stable Version
Will this version be available as a binary? Best regards, Christian -Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Sent: Friday, November 11, 2005 1:12 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Next Stable Version Christian Loock wrote: Hi Everybody, I'm writing again to ask if there are any predictions when the new version of fop will be released. This is currently expected new week. But please remember it is a preview release and should be treated as beta code. It seems fairly stable for the documents I've tried. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Large PDF - Performance
Thank you all for the suggestions. Here is what I have done so far, maybe this could help others with projects that they are working on. I ran a 1000 TRANSACTION element version of the detrpt1.xml through two different XSLT processors, both from the command line, so I could get an understanding of the XSL transformation time, taking fop out of the equation. The two XSLT processors Xalan-j - version 2_7_0 - Processing time - 2 min 10 seconds Saxon - version 8 - Processing time - 2.5 seconds I was surprised to see such a huge difference in performance, but I believe I performed the benchmarks correctly, I was just creating a text file for the test, but each created a text file of the same size, with all the data from the xml present. So now I am plugging Saxon in to the actual application and I will see what I get. I will repost to the mail list, if anything that might be helpful to others comes up. Again, thanks for all the help. Danny Gallagher The Gainer Group 6525 The Corners Parkway Suite 215 Norcross Ga, 30092 -Original Message- From: Andreas L Delmelle [mailto:[EMAIL PROTECTED] Sent: Thursday, November 10, 2005 3:16 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Large PDF - Performance On Nov 10, 2005, at 21:10, J.Pietschmann wrote: Andreas L Delmelle wrote: Oh, you might want to look into pre-compiled stylesheets, too. Saxon supports those. I don't know about Xalan. It does: see http://xml.apache.org/xalan-j/xsltc_usage.html Well, XSLTC compiles XSLT into Java. Compiled style sheets are usually a bit less drastic, it just means the style sheet is kept in a javax.xml.transform.Templates object. Sorry, my mistake. This saves parsing the XML into an internal data structure and static optimizations. Standard Xalan supports compiled style sheets in the latter sense too. Not that XSLTC is actually a completely separate code base and has quite a bit more problems than standard Xalan. Yep. Still Sun has adopted it and made it part of Java 1.5. If the stylesheet can be compiled into Java w.o. problems, it is noticeably quite a bit faster (for all but the first run, evidently). Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
I tested several XSLT processors last year - on both Linux and Windows. I also found that certain XPATH expressions produced significant differences in processing time between the different processors. (One surprise was that Saxon 6.5.3 (I think) took a long time with XPATH expressions involving '../somexpathexpression'. Just defining a variable that was '..' and using '$variable/somexpathexpression' vastly improved things.) So - I think XPATH between different processors is like SQL between different relational databases. They all do different optimisations. You need to tune your XSLT for your processor. Mike Danny wrote: Thank you all for the suggestions. Here is what I have done so far, maybe this could help others with projects that they are working on. I ran a 1000 TRANSACTION element version of the detrpt1.xml through two different XSLT processors, both from the command line, so I could get an understanding of the XSL transformation time, taking fop out of the equation. The two XSLT processors Xalan-j - version 2_7_0 - Processing time - 2 min 10 seconds Saxon - version 8 - Processing time - 2.5 seconds I was surprised to see such a huge difference in performance, but I believe I performed the benchmarks correctly, I was just creating a text file for the test, but each created a text file of the same size, with all the data from the xml present. So now I am plugging Saxon in to the actual application and I will see what I get. I will repost to the mail list, if anything that might be helpful to others comes up. Again, thanks for all the help. Danny Gallagher The Gainer Group 6525 The Corners Parkway Suite 215 Norcross Ga, 30092 Message Scanned by ClamAV on datalucid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Large PDF - Performance
I plugged saxon into my application code. 1000 TRANSACTION element report (report button click in application to pdf display to user) Before using xalan (4 minutes 20 seconds) Now using saxon (1 minute 45 seconds) Quite a difference! Danny Gallagher The Gainer Group 6525 The Corners Parkway Suite 215 Norcross Ga, 30092 -Original Message- From: Mike Trotman [mailto:[EMAIL PROTECTED] Sent: Friday, November 11, 2005 8:54 AM To: fop-users@xmlgraphics.apache.org Subject: Re: Large PDF - Performance I tested several XSLT processors last year - on both Linux and Windows. I also found that certain XPATH expressions produced significant differences in processing time between the different processors. (One surprise was that Saxon 6.5.3 (I think) took a long time with XPATH expressions involving '../somexpathexpression'. Just defining a variable that was '..' and using '$variable/somexpathexpression' vastly improved things.) So - I think XPATH between different processors is like SQL between different relational databases. They all do different optimisations. You need to tune your XSLT for your processor. Mike Danny wrote: Thank you all for the suggestions. Here is what I have done so far, maybe this could help others with projects that they are working on. I ran a 1000 TRANSACTION element version of the detrpt1.xml through two different XSLT processors, both from the command line, so I could get an understanding of the XSL transformation time, taking fop out of the equation. The two XSLT processors Xalan-j - version 2_7_0 - Processing time - 2 min 10 seconds Saxon - version 8 - Processing time - 2.5 seconds I was surprised to see such a huge difference in performance, but I believe I performed the benchmarks correctly, I was just creating a text file for the test, but each created a text file of the same size, with all the data from the xml present. So now I am plugging Saxon in to the actual application and I will see what I get. I will repost to the mail list, if anything that might be helpful to others comes up. Again, thanks for all the help. Danny Gallagher The Gainer Group 6525 The Corners Parkway Suite 215 Norcross Ga, 30092 Message Scanned by ClamAV on datalucid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
On Nov 11, 2005, at 15:27, Danny wrote: I plugged saxon into my application code. 1000 TRANSACTION element report (report button click in application to pdf display to user) Before using xalan (4 minutes 20 seconds) Now using saxon (1 minute 45 seconds) Quite a difference! In this respect, it may prove worthwhile to track down whether this difference is really caused by the XSLT processor itself, or merely by the fact that Saxon comes bundled with its own XML parser (AElfred). Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
In this respect, it may prove worthwhile to track down whether this difference is really caused by the XSLT processor itself, or merely by the fact that Saxon comes bundled with its own XML parser (AElfred). From the Aelfred web site on Sourceforge: Saxon versions from 7.2 onwards no longer include a built-in XML parser. This decision was taken because Saxon is now dependent on JDK 1.4, which includes its own XML parser, and therefore the original reason for bundling a parser with Saxon has disappeared. That listing is a bit out of date, as the last couple versions (8.5 and 8.6) of Saxon use the 1.5 JDK. So, versions 7 8 of Saxon (which provide access to XSLT 2.0) use Crimson. Version 6.x uses Aelfred. I believe the OP mentioned using Saxon 8, so the parser in question is Crimson. FWIW Jay Bryant Bryant Communication Services (presently consulting at Synergistic Solution Technologies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Saxon8
I have tried to implement Saxon8.6 in place of Xalan but am getting errors. Are there other libraries I require? Regards, Daniel [EMAIL PROTECTED] 11/11/2005 10:36 AM Please respond to fop-users@xmlgraphics.apache.org To fop-users@xmlgraphics.apache.org cc Subject Re: Large PDF - Performance In this respect, it may prove worthwhile to track down whether this difference is really caused by the XSLT processor itself, or merely by the fact that Saxon comes bundled with its own XML parser (AElfred). >From the Aelfred web site on Sourceforge: Saxon versions from 7.2 onwards no longer include a built-in XML parser. This decision was taken because Saxon is now dependent on JDK 1.4, which includes its own XML parser, and therefore the original reason for bundling a parser with Saxon has disappeared. That listing is a bit out of date, as the last couple versions (8.5 and 8.6) of Saxon use the 1.5 JDK. So, versions 7 8 of Saxon (which provide access to XSLT 2.0) use Crimson. Version 6.x uses Aelfred. I believe the OP mentioned using Saxon 8, so the parser in question is Crimson. FWIW Jay Bryant Bryant Communication Services (presently consulting at Synergistic Solution Technologies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Saxon8
On Nov 11, 2005, at 17:25, Daniel Brown wrote: I have tried to implement Saxon8.6 in place of Xalan but am getting errors. Are there other libraries I require? What kinds of error are you talking about? There should be no need for additional libraries... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Saxon8
I have tried to implement Saxon8.6 in place of Xalan but am getting errors. Are there other libraries I require? Regards, Daniel Hi, Daniel, The Saxon distribution is self-contained, so you should need no other libraries. It requires Java 1.5 (or Java 1.4 and some additional package from Sun, but I just use 1.5, so I forget the details of that bit). For questions like this, I recommend subscribing to [EMAIL PROTECTED] Mike Kay is VERY good about answering questions, often within just a few minutes (remember that he lives in England, though, so don't expect much late in the day). Jay Bryant Bryant Communication Services (presently consulting at Synergistic Solution Technologies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Saxon8
This is the error java.lang.NoClassDefFoundError: java/lang/CharSequence at net.sf.saxon.Configuration.init(Configuration.java:66) at net.sf.saxon.TransformerFactoryImpl.init(TransformerFactoryImpl.java:42) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:232) at javax.xml.transform.FactoryFinder.newInstance(FactoryFinder.java:97) at javax.xml.transform.FactoryFinder.findJarServiceProvider(FactoryFinder.java:275) at javax.xml.transform.FactoryFinder.find(FactoryFinder.java:182) at javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:100) at com.binarytree.xml.fo.Converters.convertXML2PDF(Converters.java:55) at com.binarytree.xml.fo.ConvertDBL_DOC.main(ConvertDBL_DOC.java:31) Exception in thread main Regards, Daniel Andreas L Delmelle [EMAIL PROTECTED] 11/11/2005 11:21 AM Please respond to fop-users@xmlgraphics.apache.org To fop-users@xmlgraphics.apache.org cc Subject Re: Saxon8 On Nov 11, 2005, at 17:25, Daniel Brown wrote: I have tried to implement Saxon8.6 in place of Xalan but am getting errors. Are there other libraries I require? What kinds of error are you talking about? There should be no need for additional libraries... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Saxon8
On Nov 11, 2005, at 17:51, Daniel Brown wrote: This is the error java.lang.NoClassDefFoundError: java/lang/CharSequence Hmm. Running on Java 1.3 perhaps? This interface is available in Java as of version 1.4. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP Performance
I have done just that: http://wiki.apache.org/xmlgraphics-fop/HowTo/PHPJavaBridge I linked to it on the front page as well. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Fri 11/11/2005 5:04 AM To: fop-users@xmlgraphics.apache.org Subject: Re: FOP Performance http://xmlgraphics.apache.org/fop/0.20.5/servlets.html Basically you need to: - build the sample FOP servlet as described on the above page - Download Apache Tomcat and install it as a service - Deploy FOP in Tomcat as described on the above page I know almost nothing about PHP so I wouldn't know about any better approaches to this from the PHP point of view. Maybe you can Michael Dabney to publish the details of his solution using the PHP Java Bridge on the FOP Wiki [1] under the HowTo section. His approach sounds pretty good, too. [1] http://wiki.apache.org/xmlgraphics-fop/ On 11.11.2005 11:50:23 Christian Loock wrote: I'm not very fit in all this technical stuff. Do you know any kind of documentation etc. which could help me keeping FOP in memory? Best Regards, Christian -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, November 11, 2005 11:26 AM To: fop-users@xmlgraphics.apache.org Subject: Re: FOP Performance Batik takes a long time to warm up due to its size (class loading). If you use the servlet approach, i.e. having FOP up, running and ready the whole time, it will speed up the process a lot. If you find another way to hold FOP and the VM it runs in memory over multiple rendering runs(some PHP extension, a web service or whatever), that's fine, too. Most of the time is simply lost with class loading and initialization. HTH. On 11.11.2005 10:59:45 Christian Loock wrote: Hi again! The Performance problem figured out to be a problem in using SVG images as Backgorund images for the xsl-region-before/after/start/end. Any ideas on how to fix this problem without changing to another picture format. (jpg and gif do look bad imho) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP Performance
On Nov 11, 2005, at 21:11, Michael Dabney wrote: Hi Michael, I have done just that: http://wiki.apache.org/xmlgraphics-fop/HowTo/ PHPJavaBridge I linked to it on the front page as well. Thanks a lot for taking the time to do this! May need some minor tweaks to make it relevant for FOP Trunk, which will be released next week, but just wanted to let you know that your contribution is much appreciated. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
Andreas L Delmelle wrote: In this respect, it may prove worthwhile to track down whether this difference is really caused by the XSLT processor itself, or merely by the fact that Saxon comes bundled with its own XML parser (AElfred). Saxon uses a more efficient internal data storage, and also has much better optimizations, both static and run-time. I believe the more compact data representation is the winner, which also allows transformation up to ten times the size Xalan can manage. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP Performance
Yeah, this is definitely 0.20.5 specific. On Nov 11, 2005, at 21:11, Michael Dabney wrote: Hi Michael, I have done just that: http://wiki.apache.org/xmlgraphics-fop/HowTo/ PHPJavaBridge I linked to it on the front page as well. Thanks a lot for taking the time to do this! May need some minor tweaks to make it relevant for FOP Trunk, which will be released next week, but just wanted to let you know that your contribution is much appreciated. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Large PDF - Performance
Ok, so continuing from where I was. I plugged saxon into my application (JAVA) code. 1000 TRANSACTION element report (report button click in application to pdf display to user) Before using xalan (4 minutes 20 seconds) Now using saxon (1 minute 45 seconds) The only change that I had to make to the application was to set the system property javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl so that the application would use saxon instead of the default (xalan). And adding the saxon8.jar, of course. So that all worked great, for a little while. Now the report is taking as long as it did before for some reason and I have no idea why. I verified that the application is using the saxon transformer in two ways: 1. By specifying the xsl:vendor in the xsl. 2. By making sure that the class that is returned from the TransformerFactory is an instance of net.sf.saxon.Controller I restarted the application multiple times, even rebooted my PC, to no avail. Anyone ever seen this type of behavior before? Thanks Danny Gallagher The Gainer Group 6525 The Corners Parkway Suite 215 Norcross Ga, 30092 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Friday, November 11, 2005 4:18 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Large PDF - Performance Andreas L Delmelle wrote: In this respect, it may prove worthwhile to track down whether this difference is really caused by the XSLT processor itself, or merely by the fact that Saxon comes bundled with its own XML parser (AElfred). Saxon uses a more efficient internal data storage, and also has much better optimizations, both static and run-time. I believe the more compact data representation is the winner, which also allows transformation up to ten times the size Xalan can manage. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
