RE: FOP 1.0 - properties which don't make same result than 0.20.5 version
Hi Andreas, Thanks a lot, this helps me. I didn't know it was possible to stack areas, which is quite powerful. :-) Regards. - Nicolas SALIC Agrostar DOP DEV 02.97.48.56.23 "Communication gratuite en interne !" Theix Rue Jacques Cartier, BP 165 Theix, 56005 Vannes Cedex, 56450 Theix -Message d'origine- De : Andreas Delmelle [mailto:andreas.delme...@telenet.be] Envoyé : lundi 10 janvier 2011 19:55 À : fop-users@xmlgraphics.apache.org Objet : Re: FOP 1.0 - properties which don't make same result than 0.20.5 version On 10 Jan 2011, at 17:46, (Ext.) Nicolas Salic wrote: Hi Nicolas > I'm testing FOP 1.0 with stylesheets currently working with FOP 0.20.5, and I > get different results with two properties. > The height property at fo:table level doesn't give me the same result, > neither the border-style property at fo:table-column level. > > Here is the code I use : As far as I know, in FOP 1.0: - "height" or "block-progression-dimension" does not work at all on fo:table - in case of cells spanning multiple colums, the specified column-borders are only painted on the cell's start & end (= left & right) edges For the first issue, there is a quite straightforward workaround: specify "height" or "block-progression-dimension" on the one fo:table-row instead, where it does have the intended effect. Depending on the use case, you may want to use "min-height" if the table may still grow beyond the desired height. For the second issue, the workaround is not so straightforward, but it could be feasible. It looks slightly convoluted, but below is as close as I could get to your 0.20.5 output with FOP 1.0. Note that there seems to be a slight issue with the height of the row. In order to get it to match the height of the inner table exactly, I had to subtract the cell-padding, which does not seem entirely correct (?) http://www.w3.org/1999/XSL/Format";> Ceci est un texte sur plusieurs cellules Hope this helps! Regards, Andreas Delmelle --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
SVG in FOP 1.0
I am developing two web based prototypes for rendering PDF using XSL-FO. First prototype is a Java Servlet deployed in Tomcat container in windows environment. The servlet renders PDFs to web as well as windows based clients. Everything works well, till I decided to add SVG elements to generate 3D charts. I am using pre-compiled version of FOP 1.0. Looking at the manifest file for FOP.jar, I noticed that jai_*.jar files have not been referenced. If I include following jar files, I am able to generate 3D graphs using SVG. jai_codec.jar jai_core.jar jai_imageio.jar Are these jar files sufficient for FOP to process SVG elements? I thought that batik-all-1.7.jar should be sufficient to process SVG elements. I guess I was wrong. Second prototype is .NET based solution, where I have converted FOP 1.0 to a single .NET DLL using IKVM. Same issue here with SVG elements but even if I include the jai_*.jar files in my .NET dll, still the SVG elements are ignored. There are issues mentioned with class loader functionality in the following article. But this article was published in 2004, I bet there have been considerable improvements in IKVM since then. http://onjava.com/pub/a/onjava/2004/08/18/ikvm.html == Begin - Excerpt from the article Second is the ikvmc command, which can be used to convert Java bytecodes into .NET IL. Thus, you can convert a set of Java class files into a .NET assembly. Since this manner of use statically compiles the Java bytecodes, it's known as the static mode. Note that while the dynamic mode fully supports the Java classloader semantics, in the static mode, there are necessarily some limitations. Among the issues to watch out for is the fact that all classes are loaded by the bootstrap classloader. See the threads for the gory details. In brief, many Java programs assume this.class.getClassLoader() will return non-null. That, however, is not a valid assumption for classes loaded by the bootstrap loader. Also, while classloader functionality (such as Class.forName(..)) is available to use, and indeed can be used to load either statically compiled classes or Java bytecode, remember that loading classes out of .NET assemblies that are not referenced directly or indirectly from your application may not work without manual intervention. See the documentation for more detail on this and other hairy issues that arise when two different worlds collide! == End - Excerpt from the article I do understand that this is FOP user's email group, so IKVM related issue may not be answered, but if anyone has experience using SVG elements in .XSLT file, can point me to the right jar files (other than mentioned above). Thanks in advance for your help. Regards, Jayant - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: SVG in FOP 1.0
I think we'd have to see some sample code to tell if jai is required or if you're missing something else. I know the FOP ant build has some optional tests based on whether jai is available, and I do create SVG graphics in my normal processing where jai is not in the classpath. -Original Message- From: Jayant Ghagre [mailto:jayant.gha...@ambest.com] Sent: Tuesday, January 11, 2011 11:41 AM To: fop-users@xmlgraphics.apache.org Subject: SVG in FOP 1.0 I am developing two web based prototypes for rendering PDF using XSL-FO. First prototype is a Java Servlet deployed in Tomcat container in windows environment. The servlet renders PDFs to web as well as windows based clients. Everything works well, till I decided to add SVG elements to generate 3D charts. I am using pre-compiled version of FOP 1.0. Looking at the manifest file for FOP.jar, I noticed that jai_*.jar files have not been referenced. If I include following jar files, I am able to generate 3D graphs using SVG. jai_codec.jar jai_core.jar jai_imageio.jar Are these jar files sufficient for FOP to process SVG elements? I thought that batik-all-1.7.jar should be sufficient to process SVG elements. I guess I was wrong. Second prototype is .NET based solution, where I have converted FOP 1.0 to a single .NET DLL using IKVM. Same issue here with SVG elements but even if I include the jai_*.jar files in my .NET dll, still the SVG elements are ignored. There are issues mentioned with class loader functionality in the following article. But this article was published in 2004, I bet there have been considerable improvements in IKVM since then. http://onjava.com/pub/a/onjava/2004/08/18/ikvm.html == Begin - Excerpt from the article Second is the ikvmc command, which can be used to convert Java bytecodes into .NET IL. Thus, you can convert a set of Java class files into a .NET assembly. Since this manner of use statically compiles the Java bytecodes, it's known as the static mode. Note that while the dynamic mode fully supports the Java classloader semantics, in the static mode, there are necessarily some limitations. Among the issues to watch out for is the fact that all classes are loaded by the bootstrap classloader. See the threads for the gory details. In brief, many Java programs assume this.class.getClassLoader() will return non-null. That, however, is not a valid assumption for classes loaded by the bootstrap loader. Also, while classloader functionality (such as Class.forName(..)) is available to use, and indeed can be used to load either statically compiled classes or Java bytecode, remember that loading classes out of .NET assemblies that are not referenced directly or indirectly from your application may not work without manual intervention. See the documentation for more detail on this and other hairy issues that arise when two different worlds collide! == End - Excerpt from the article I do understand that this is FOP user's email group, so IKVM related issue may not be answered, but if anyone has experience using SVG elements in .XSLT file, can point me to the right jar files (other than mentioned above). Thanks in advance for your help. Regards, Jayant - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Rendering differences: fop-0.95 vs fop.-1.0
On 11 Jan 2011, at 14:20, Rob Sargent wrote: Hi Rob > > I've proven to myself that I'm generating identical xml, but getting > malformed pdf in version 1.0 where 0.95 was perfectly happy. > > I'm getting some clipping along the inner (left) side of right-hand pages in > static region-before but only on some pages. Not all pages, however. It > looks as if I've over-lain a high-precedence region-start but it's not in my > code :) > > Has anyone seen anything like this? > Attaching the fo.xml for anyone that's curious. In the future, please pay us curious folk the courtesy of either: a) providing the *smallest possible* sample reproducing the issue, or b) describing your issue in more detail Just mentioning, since, IIC, you sent us about 23 pages of content too many... Thanks in advance! With that many pages and such a vague description, it is hard to see exactly what 'malformed pdf' you are referring to. Do I get it correct that you mean the effect that is visible on page 2? In that case, do mind that the region-before cannot grow beyond the specified extent of 1.5in. If it does, it will overlap the region-body, whether you intended it or not. I am unsure what exactly 0.95 did differently, but I am quite sure that that combination of block and nested tables will be too big to fit in the space of 1.5in. You can see that if you remove the second row of the innermost table (containing the block with text 'asdf'). After doing that, the page seems to look as it should. Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Rendering differences: fop-0.95 vs fop.-1.0
My apologies for the size of the fo file. If I knew where the problem was in particular I certain would have trimmed it. I'll follow-up on your suggestions, for which I am most thankful. I sent the whole thing since there are pdf differences on "most" of the right hand pages, all of which printed nicely under 0.95. If I have to adjust the calculation of the table size (vertically) in fop-1.0 so be it. Thanks again, rjs On 01/11/2011 11:09 AM, Andreas Delmelle wrote: > On 11 Jan 2011, at 14:20, Rob Sargent wrote: > > Hi Rob > > >> I've proven to myself that I'm generating identical xml, but getting >> malformed pdf in version 1.0 where 0.95 was perfectly happy. >> >> I'm getting some clipping along the inner (left) side of right-hand pages in >> static region-before but only on some pages. Not all pages, however. It >> looks as if I've over-lain a high-precedence region-start but it's not in my >> code :) >> >> Has anyone seen anything like this? >> Attaching the fo.xml for anyone that's curious. >> > In the future, please pay us curious folk the courtesy of either: > a) providing the *smallest possible* sample reproducing the issue, or > b) describing your issue in more detail > > Just mentioning, since, IIC, you sent us about 23 pages of content too > many... Thanks in advance! > > With that many pages and such a vague description, it is hard to see exactly > what 'malformed pdf' you are referring to. > > Do I get it correct that you mean the effect that is visible on page 2? > In that case, do mind that the region-before cannot grow beyond the specified > extent of 1.5in. If it does, it will overlap the region-body, whether you > intended it or not. > > I am unsure what exactly 0.95 did differently, but I am quite sure that that > combination of block and nested tables will be too big to fit in the space of > 1.5in. You can see that if you remove the second row of the innermost table > (containing the block with text 'asdf'). After doing that, the page seems to > look as it should. > > > > Regards > > Andreas > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Rendering differences: fop-0.95 vs fop.-1.0
On 11 Jan 2011, at 19:31, Rob Sargent wrote: > My apologies for the size of the fo file. If I knew where the problem > was in particular I certain would have trimmed it. OK, no harm done. > I'll follow-up on your suggestions, for which I am most thankful. > I sent the whole thing since there are pdf differences on "most" > of the right hand pages, all of which printed nicely under 0.95. If you can be more specific, don't hold back. Quite some time and commits passed between 0.95 and 1.0, so I cannot exclude the possibility that there are regressions among those differences. The more accurate you can tell what appears wrong, the better we will be able to judge whether they are genuine bugs or just 'natural' (and in XSL-FO, the latter is at times counter-intuitive...). Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Rendering differences: fop-0.95 vs fop.-1.0
On 01/11/2011 11:46 AM, Andreas Delmelle wrote: > On 11 Jan 2011, at 19:31, Rob Sargent wrote: > > >> My apologies for the size of the fo file. If I knew where the problem >> was in particular I certain would have trimmed it. >> > OK, no harm done. > > >> I'll follow-up on your suggestions, for which I am most thankful. >> I sent the whole thing since there are pdf differences on "most" >> of the right hand pages, all of which printed nicely under 0.95. >> > If you can be more specific, don't hold back. Quite some time and commits > passed between 0.95 and 1.0, so I cannot exclude the possibility that there > are regressions among those differences. The more accurate you can tell what > appears wrong, the better we will be able to judge whether they are genuine > bugs or just 'natural' (and in XSL-FO, the latter is at times > counter-intuitive...). > > > Regards, > > Andreas > --- > > Once I nail the culprit (table size calculation or what ever) I'll try to report back the difference. Stay tuned (patiently :) ) > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: SVG in FOP 1.0
Eric, My servlet code is pretty much same as FopServlet.java file from src\java \org\apache\fop\servlet folder. I am attaching sample Xslt and XML data file. One more thing, PDF generated using command line FOP has no issues. (See attached file: SampleXSLT.xslt)(See attached file: Data.xml)(See attached file: FopServlet.java) Thanks. Regards, Jayant |> | From: | |> >--| |"Eric Douglas" | >--| |> | To:| |> >--| | | >--| |> | Date: | |> >--| |01/11/2011 11:48 AM | >--| |> | Subject: | |> >--| |RE: SVG in FOP 1.0 | >--| I think we'd have to see some sample code to tell if jai is required or if you're missing something else. I know the FOP ant build has some optional tests based on whether jai is available, and I do create SVG graphics in my normal processing where jai is not in the classpath. -Original Message- From: Jayant Ghagre [mailto:jayant.gha...@ambest.com] Sent: Tuesday, January 11, 2011 11:41 AM To: fop-users@xmlgraphics.apache.org Subject: SVG in FOP 1.0 I am developing two web based prototypes for rendering PDF using XSL-FO. First prototype is a Java Servlet deployed in Tomcat container in windows environment. The servlet renders PDFs to web as well as windows based clients. Everything works well, till I decided to add SVG elements to generate 3D charts. I am using pre-compiled version of FOP 1.0. Looking at the manifest file for FOP.jar, I noticed that jai_*.jar files have not been referenced. If I include following jar files, I am able to generate 3D graphs using SVG. jai_codec.jar jai_core.jar jai_imageio.jar Are these jar files sufficient for FOP to process SVG elements? I thought that batik-all-1.7.jar should be sufficient to process SVG elements. I guess I was wrong. Second prototype is .NET based solution, where I have converted FOP 1.0 to a single .NET DLL using IKVM. Same issue here with SVG elements but even if I include the jai_*.jar files in my .NET dll, still the SVG elements are ignored. There are issues mentioned with class loader functionality in the following article. But this article was published in 2004, I bet there have been considerable improvements in IKVM since then. http://onjava.com/pub/a/onjava/2004/08/18/ikvm.html == Begin - Excerpt from the article Second is the ikvmc command, which can be used to convert Java bytecodes into .NET IL. Thus, you can convert a set of Java class files into a .NET assembly. Since this manner of use statically compiles the Java bytecodes, it's known as the static mode. Note that while the dynamic mode fully supports the Java classloader semantics, in the static mode, there are necessarily some limitations. Among the issues to watch out for is the fact that all classes are loaded by the bootstrap classloader. See the threads for the gory details. In brief, many Java programs assume this.class.getClassLoader() will return non-null. That, however, is not a valid assumption for classes loaded by the bootstrap loader. Also, while classloader functionality (such as Class.forName(..)) is available to use, and indeed can be used to load either statically compiled classes or Java bytecode, remember that loading classes out of .NET assemblies that are not referenc
