Re: Still need DOM Tree processing?
On 07.07.2004 05:41:11 Glen Mazza wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: Using a DOMSource and a SAXResult with an identity transformer. Do we already have an example for this one? I'm not sure of what you mean--are you saying that Manuel can continue doing exactly what he's doing (slurping a FO file into a DOM Tree, manipulating the tree by adding RDBMS values to it, then sending the DOM Tree off to FOP to be published) with what you mention above? Yes, exactly. Take the XML2PDF example. I'm copying the important part and only have to change two lines to (1) use the identity transformer instead of an XSLT stylesheet and (2) using a DOM as source instead of an XML file. driver.setOutputStream(out); // Setup XSLT TransformerFactory factory = TransformerFactory.newInstance(); //Transformer transformer = factory.newTransformer(new StreamSource(xsltfile)); Transformer transformer = factory.newTransformer(); //identity transformer // Setup input for XSLT transformation //Source src = new StreamSource(xmlfile); Source src = new DOMSource(mydomnode); // Resulting SAX events (the generated FO) must be piped through to FOP Result res = new SAXResult(driver.getContentHandler()); // Start XSLT transformation and FOP processing transformer.transform(src, res); Also, under the hood, do you suspect that the identity transformer is the same thing as our two classes? I'm far from an expert at this. Not the same, but has the same effect. On the other side, the two classes are perfectly usable and useful stand-alone outside of FOP. I would guess those two classes are a dime a dozen, probably in 100 articles and books. But a non-FOP user can always take the source code and incorporate them in his/her program. That's right. But FOP is not XML Commons, and IMO external users should not be directly latching on to non-XSL portions (i.e., not fonts or hyphenation, etc., things that we are expected to share) of our code that way. That would limit our ability to modify/optimize/simplify the code to provide a solid XSL implementation. I'm not sure I understand this paragraph correctly. Does that mean that you will be against factoring out certain basic components from FOP into a separate area so they can be more easily reused by others and improved by people not really seeing through FOP's code forrest? In the end I don't see what is gained by moving these two classes around and by reducing their visibility. My thinking: We can get rid of them in the future, without worrying about backwards compatibility. Ok. We can move, rename, merge, modify them without worrying about external use. Yes, but what's the benefit about moving them around when they were in a place where nobody was bothered by them and they were doing their job? Fewer moving parts and fewer access paths means fewer bugs and less confusion both on the FOP-USER list as well as with developers. Well, these two classes are certainly not cause to any pain. If I've seen that correctly the code has never been semantically changed sence its separation from the Driver code in 2001. Kelly Campbell wrote then: Refactored Driver to simplify usage required for other apps to integrate Fop. Also, we're placing them precisely in the package, and the only package, in which they're being called. This makes the packages less dependent on each other. But the visibility is actually less important to me than the location. If it would make you more comfortable, I'm willing to make them public, but I would prefer them to stay in apps. (We can also wait first until we get hate mail--exposing them is very simple--but if we never get such mail we know they are no longer needed.) There is a good chance that nobody uses this code at all, yes. But in all no strong points IMHO to motivate this change. NTARS. It's simply a fact that many people still work with a DOM and I know a few programmers who are very hard to talk into adopting a different style of dealing with XML. They won't need to--we will happily continue to be supporting DOM Trees within FOP. Moving them to apps also shows their first-class ranking alongside XSLTInputHandler and FOInputHandler. Ok, I will shut up about this now. Jeremias Maerki
Re: Still need DOM Tree processing?
--- Jeremias Maerki [EMAIL PROTECTED] wrote: But FOP is not XML Commons, and IMO external users should not be directly latching on to non-XSL portions (i.e., not fonts or hyphenation, etc., things that we are expected to share) of our code that way. That would limit our ability to modify/optimize/simplify the code to provide a solid XSL implementation. I'm not sure I understand this paragraph correctly. Does that mean that you will be against factoring out certain basic components from FOP into a separate area so they can be more easily reused by others and improved by people not really seeing through FOP's code forrest? No, what you're suggesting is the way I would propose it. In a typical case of reuse, code would be taken out of FOP, sent to XML Commons or the XML Graphics components, and imported back into FOP as a library. Possible exceptions are those by definition classes that FOP should be exposing, by virtue of the type of application it is. As you can tell, I'm fuzzy on this. Let's discuss these on a case-by-case basis after XML Graphics forms. It's just our FOP infrastructure/internal code that I wouldn't want users to be directly importing into their apps: that code is subject to change, renaming, removal, etc. I judged the two classes in question to be more or less just an internal implementation of how we were handling things. import org.apache.fop.apps/tools.DocumentReader from user code is not something I would want us to be supporting in the future. Supplying identity transform alternatives is outside the scope of FOP; in the unlikely event we ever get demand for these two classes we can send those classes to XML Commons, so the user can import org.apache.xml.commons. instead. Glen
Re: Still need DOM Tree processing?
A bit late to react but I'm not 100% happy with moving the two classes into apps. I was a bit surprised at the time you introduced the DOM example because the same functionality could be provided via JAXP: Using a DOMSource and a SAXResult with an identity transformer. The examples were meant to show best practices by using widely known APIs. FOP's direct support for DOM predates JAXP and, today, is presented to our users as a convenience only (my opinion). On the other side, the two classes are perfectly usable and useful stand-alone outside of FOP. In the end I don't see what is gained by moving these two classes around and by reducing their visibility. It's simply a fact that many people still work with a DOM and I know a few programmers who are very hard to talk into adopting a different style of dealing with XML. On 04.07.2004 22:23:17 Glen Mazza wrote: Team, We allow--and have for many years--for input processing of FO documents in the form of DOM trees. Several months back I created an example [1] of a Hello World FO document to show how this functionality might be used. The (well-written) classes which provide this functionality, tools.DocumentReader and tools.DocumentInputSource [2], date to March 2001 when it was factored out of code in Apps.Driver. The original code in Driver that provided this functionality predates 2000, when original author James Tauber was coding FOP [3]. But does anyone generate FO documents via DOM Trees anymore? This style of coding appears to come from the days that SAX wasn't as well known as DOM. The example I gave would be very cumbersome and hard-to-maintain for any non-trivial sized FO document. Although one potential use could be reading an FO file into a DOM Tree, navigating the tree, and manipulating its values, it would appear the standard today in these cases would be to just use xsl:param and setParameter() as here [4]. If this style of coding is obsolete, I would like to remove this functionality from our API in HEAD--we can return it back fairly easily if we start getting hate mail as FOP 1.0 solidifies and gets more use. In addition to removing the two classes above, it would also allow me to simplify/streamline apps.Driver a bit more, and I can also remove my example given on the Embed page. Jeremias Maerki
Re: Still need DOM Tree processing?
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Using a DOMSource and a SAXResult with an identity transformer. Do we already have an example for this one? I'm not sure of what you mean--are you saying that Manuel can continue doing exactly what he's doing (slurping a FO file into a DOM Tree, manipulating the tree by adding RDBMS values to it, then sending the DOM Tree off to FOP to be published) with what you mention above? Also, under the hood, do you suspect that the identity transformer is the same thing as our two classes? I'm far from an expert at this. On the other side, the two classes are perfectly usable and useful stand-alone outside of FOP. I would guess those two classes are a dime a dozen, probably in 100 articles and books. But a non-FOP user can always take the source code and incorporate them in his/her program. But FOP is not XML Commons, and IMO external users should not be directly latching on to non-XSL portions (i.e., not fonts or hyphenation, etc., things that we are expected to share) of our code that way. That would limit our ability to modify/optimize/simplify the code to provide a solid XSL implementation. In the end I don't see what is gained by moving these two classes around and by reducing their visibility. My thinking: We can get rid of them in the future, without worrying about backwards compatibility. We can move, rename, merge, modify them without worrying about external use. Fewer moving parts and fewer access paths means fewer bugs and less confusion both on the FOP-USER list as well as with developers. Also, we're placing them precisely in the package, and the only package, in which they're being called. This makes the packages less dependent on each other. But the visibility is actually less important to me than the location. If it would make you more comfortable, I'm willing to make them public, but I would prefer them to stay in apps. (We can also wait first until we get hate mail--exposing them is very simple--but if we never get such mail we know they are no longer needed.) It's simply a fact that many people still work with a DOM and I know a few programmers who are very hard to talk into adopting a different style of dealing with XML. They won't need to--we will happily continue to be supporting DOM Trees within FOP. Moving them to apps also shows their first-class ranking alongside XSLTInputHandler and FOInputHandler. Thanks, Glen
Re: Still need DOM Tree processing?
Thanks for the information. Working with a DOM tree saves one the step of needing to place input data into XML first. So retaining this functionality in 1.0 will keep the flexibility to users in how they can approach a report-generation task. I guess we should keep it in then. Thanks, Glen --- Manuel Mall [EMAIL PROTECTED] wrote: Glen, A 1. We do preload an FO file into a DOM tree, navigate it, do manipulations, and then send it off to be published into PDF. A 2. At the time it seemed the easier way of doing it. Would we still be doing it again instead of using XSLT? Hmm, our input data is not in XML but comes from a RDBMS and other sources. So we would have to convert this into custom XML and restructure our current FO files to become XSLT stylesheets. Its doable and would certainly be more standards compliant. Would it be simpler / easier? As it stands now for any formatting changes we just edit the FO file. In future it would mean editing the XSL file = No loss or gain. For data structure changes we need to modify the FO file and the code setting up the final DOM tree. In future we would need to change the XSL and the code creating the XML from the data = Again no loss or gain. Manuel - Original Message - From: Glen Mazza [EMAIL PROTECTED] Thanks--you're the first I've heard using it. May I ask: 1) Do you manually create the FO document from scratch similar to the first example I gave in my previous email? Or, do you preload an FO file into a DOM tree, navigate it, do minor manipulations, and then send it off to be published into PDF? 2) Is using DOM Trees an optimal way for you to do your work, or is it just legacy code you don't wish to disturb? (I.e., if you had to rewrite it from the beginning, would you still use DOM Trees?) Glen --- Manuel Mall [EMAIL PROTECTED] wrote: From: Glen Mazza [EMAIL PROTECTED] Team, But does anyone generate FO documents via DOM Trees anymore? Yes, we do in a back office fop intensive server application. Manuel
Re: Still need DOM Tree processing?
On Mon, Jul 05, 2004 at 11:20:26AM -0700, Glen Mazza wrote: Thanks for the information. Working with a DOM tree saves one the step of needing to place input data into XML first. So retaining this functionality in 1.0 will keep the flexibility to users in how they can approach a report-generation task. I guess we should keep it in then. I support that decision. It is one more entry point for apps. Of course they can fire off their own SAX events, but if they have a DOM tree and FOP does it for them, that is nice. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Still need DOM Tree processing?
From: Glen Mazza [EMAIL PROTECTED] Team, But does anyone generate FO documents via DOM Trees anymore? Yes, we do in a back office fop intensive server application. Manuel
Re: Still need DOM Tree processing?
Thanks--you're the first I've heard using it. May I ask: 1) Do you manually create the FO document from scratch similar to the first example I gave in my previous email? Or, do you preload an FO file into a DOM tree, navigate it, do minor manipulations, and then send it off to be published into PDF? 2) Is using DOM Trees an optimal way for you to do your work, or is it just legacy code you don't wish to disturb? (I.e., if you had to rewrite it from the beginning, would you still use DOM Trees?) Glen --- Manuel Mall [EMAIL PROTECTED] wrote: From: Glen Mazza [EMAIL PROTECTED] Team, But does anyone generate FO documents via DOM Trees anymore? Yes, we do in a back office fop intensive server application. Manuel
Re: Still need DOM Tree processing?
Glen, A 1. We do preload an FO file into a DOM tree, navigate it, do manipulations, and then send it off to be published into PDF. A 2. At the time it seemed the easier way of doing it. Would we still be doing it again instead of using XSLT? Hmm, our input data is not in XML but comes from a RDBMS and other sources. So we would have to convert this into custom XML and restructure our current FO files to become XSLT stylesheets. Its doable and would certainly be more standards compliant. Would it be simpler / easier? As it stands now for any formatting changes we just edit the FO file. In future it would mean editing the XSL file = No loss or gain. For data structure changes we need to modify the FO file and the code setting up the final DOM tree. In future we would need to change the XSL and the code creating the XML from the data = Again no loss or gain. Manuel - Original Message - From: Glen Mazza [EMAIL PROTECTED] Thanks--you're the first I've heard using it. May I ask: 1) Do you manually create the FO document from scratch similar to the first example I gave in my previous email? Or, do you preload an FO file into a DOM tree, navigate it, do minor manipulations, and then send it off to be published into PDF? 2) Is using DOM Trees an optimal way for you to do your work, or is it just legacy code you don't wish to disturb? (I.e., if you had to rewrite it from the beginning, would you still use DOM Trees?) Glen --- Manuel Mall [EMAIL PROTECTED] wrote: From: Glen Mazza [EMAIL PROTECTED] Team, But does anyone generate FO documents via DOM Trees anymore? Yes, we do in a back office fop intensive server application. Manuel
testing DOM input
I created a ExampleDOM2PDF class for general testing and demonstration of FOP's DOM Document handling abilities. It's in the same examples/embedded/java/embedded directory as the other embedded examples. Going against 1.0, the code appears to work fine, so Victor's recent Document-handling changes in Driver doesn't appear to have raised any problems. Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: testing DOM input
Glen Mazza wrote: Going against 1.0, the code appears to work fine, so Victor's recent Document-handling changes in Driver doesn't appear to have raised any problems. Thanks for checking that. Someday I'll try to mess with the embedded stuff more Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DOM
I am a new user of FOP but i want to use Xerces and i don't know how can install it. When i use the samples from Xerces the java compiler tell me org.w3c.dom.Document doesn't exist. Thanks a lot. Antonio M. Marín FernándezSADIEL, S.A.c/ Isaac Newton s/n Edificio Sadiel - Sodean, Isla de la Cartuja41092 SEVILLATel. 955064712 Tel. 955043600 Fax 955043601http://www.sadiel.es e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5075] New: - problems with DOM input
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5075. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5075 problems with DOM input Summary: problems with DOM input Product: Fop Version: all Platform: All OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, FOP does not work using DOM inputSource. the xsl-fo -document is valid: when i save it to disk and read it from a file (render it from a stream), everything works fine. so the problem seems to be with DOM. basically I am doing everything like is done in the demo servlet that comes with FOP (org.apache.fop.tools.servlet.FopServlet) BUT: i am reading from a DOMInputSource. the server announces a NullPointerException at FOTreeBuilder.java:191. (I try to attach the error messages (with xsl-fo source) to this bug report) I am using FOP v0.20.1. (I am using bea weblogic server and xalan and xerces that come with it (xerces based on version 1.3.1 of Apache Xerces and xalan based on version 2.0.1 of Apache Xalan, JDK 130. I tried to solve the problem building FOP again using this JDK, did not help. and anyway the problem seems to be inside FOP) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5075] - problems with DOM input
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5075. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5075 problems with DOM input --- Additional Comments From [EMAIL PROTECTED] 2001-11-26 03:12 --- Created an attachment (id=823) the xml source used when the error occured - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5075] - problems with DOM input
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5075. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5075 problems with DOM input --- Additional Comments From [EMAIL PROTECTED] 2001-11-26 03:14 --- Created an attachment (id=824) the xsl source used when the error occured - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: Does render(dom) actually work?
Hi Savino, hi Suhail, hi group! In the moment I transform my source-xml to a ByteArrayOutputStream and then use a ByteArrayInputStream as input for FOP. I tried to do it the same way as Suhails example, but I get the same error Savino got. How can I be sure there are no nulls in the source?? Christian -Ursprüngliche Nachricht- Von: Suhail Rashid [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 20. September 2001 06:29 An: [EMAIL PROTECTED] Betreff: RE: Does render(dom) actually work? Hi Savino, Make sure there are NO nulls making their way into the text nodes of your xml stream. these would not give problems if u wrote the xml to a file first suhail -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 3:59 AM To: '[EMAIL PROTECTED]' Subject: RE: Does render(dom) actually work? Yuri, thanks for your help. I tried your solution and I still get the following error: building formatting object tree building formatting object tree javax.xml.transform.TransformerException at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm pl.j ava:1212) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) - java.lang.NullPointerException at org.apache.fop.fo.FOTreeBuilder.startDocument(FOTreeBuilder.java:167) at org.apache.xalan.transformer.QueuedStartDocument.flush(QueuedStartDocume nt.j ava:108) at org.apache.xalan.transformer.ResultTreeHandler.flushPending(ResultTreeHa ndle r.java:758) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHa ndle r.java:245) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHa ndle r.java:209) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.j ava: 704) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Trans form erImpl.java:2154) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Trans form erImpl.java:2097) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Transfo rmer Impl.java:2029) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm pl.j ava:1189) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) It looks very similar to the one before to me. Has anyone tried this with v.0.20.1 yet? Should it say building formatting object tree twice? I'm wondering if this is some kind of issue with namespaces and the DOM2 implementation. Anyone have any ideas? By the way, if I use a DOMResult instead of a SAXResult I get no error. I then serialized the DOMResult to a file and FO works fine with that file as an input. Thanks, Matt -Original Message- From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 2:03 PM To: '[EMAIL PROTECTED]' Subject: RE: Does render(dom) actually work? Matt, Why don't you do it all in one pass? I have a servlet, that calls some bean to get XML document in a DOM format (actually JDOM), then registers fop driver as receiver of SAX events and runs XSLT on the JDOM tree. // 1. Generate XML tree Document xmlSummary = DataLoader.getSummary(); // 2. Get stylesheet transformer Transformer transformer = transformerFactory.getTransformer( xsl-file ); // 3. Create FOP driver and set rendering mode and output stream org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(driver.RENDER_PDF); driver.setOutputStream( out ); // 4. Create SAXResult based on FOP Driver content handler which will accept // SAX events and build FOP tree javax.xml.transform.sax.SAXResult saxResult = new javax.xml.transform.sax.SAXResult( driver.getContentHandler() ); // 5. Use the Transformer to transform an XML Source and send the output // to a Result object. // Implicitely it will create the FOP tree by firing SAX events transformer.transform( new org.jdom.transform.JDOMSource( xml ), saxResult ); YS -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 4:33 PM To: '[EMAIL PROTECTED]' Subject: Does render(dom) actually work? Hello everyone. By any chance can someone point me to some example code which uses render(dom
Re: Does render(dom) actually work?
Hi, This may be a problem that I have fixed. The line number (167) doesn't seem to match anything I can find so I'm not sure. There was a problem where text outside the root element would cause a null pointer exception. Actually after a second look I think it was due to the stream redner changes. Could you try the current cvs and see if that helps. Thanks Keiron On Thu, 20 Sep 2001 08:46:08 Beer, Christian wrote: Hi Savino, hi Suhail, hi group! In the moment I transform my source-xml to a ByteArrayOutputStream and then use a ByteArrayInputStream as input for FOP. I tried to do it the same way as Suhails example, but I get the same error Savino got. How can I be sure there are no nulls in the source?? Christian -Ursprüngliche Nachricht- Von: Suhail Rashid [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 20. September 2001 06:29 An: [EMAIL PROTECTED] Betreff: RE: Does render(dom) actually work? Hi Savino, Make sure there are NO nulls making their way into the text nodes of your xml stream. these would not give problems if u wrote the xml to a file first suhail -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 3:59 AM To: '[EMAIL PROTECTED]' Subject: RE: Does render(dom) actually work? Yuri, thanks for your help. I tried your solution and I still get the following error: building formatting object tree building formatting object tree javax.xml.transform.TransformerException at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm pl.j ava:1212) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) - java.lang.NullPointerException at org.apache.fop.fo.FOTreeBuilder.startDocument(FOTreeBuilder.java:167) at org.apache.xalan.transformer.QueuedStartDocument.flush(QueuedStartDocume nt.j ava:108) at org.apache.xalan.transformer.ResultTreeHandler.flushPending(ResultTreeHa ndle r.java:758) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHa ndle r.java:245) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHa ndle r.java:209) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.j ava: 704) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Trans form erImpl.java:2154) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Trans form erImpl.java:2097) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Transfo rmer Impl.java:2029) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm pl.j ava:1189) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) It looks very similar to the one before to me. Has anyone tried this with v.0.20.1 yet? Should it say building formatting object tree twice? I'm wondering if this is some kind of issue with namespaces and the DOM2 implementation. Anyone have any ideas? By the way, if I use a DOMResult instead of a SAXResult I get no error. I then serialized the DOMResult to a file and FO works fine with that file as an input. Thanks, Matt -Original Message- From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 2:03 PM To: '[EMAIL PROTECTED]' Subject: RE: Does render(dom) actually work? Matt, Why don't you do it all in one pass? I have a servlet, that calls some bean to get XML document in a DOM format (actually JDOM), then registers fop driver as receiver of SAX events and runs XSLT on the JDOM tree. // 1. Generate XML tree Document xmlSummary = DataLoader.getSummary(); // 2. Get stylesheet transformer Transformer transformer = transformerFactory.getTransformer( xsl-file ); // 3. Create FOP driver and set rendering mode and output stream org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(driver.RENDER_PDF); driver.setOutputStream( out ); // 4. Create SAXResult based on FOP Driver content handler which will accept // SAX events and build FOP tree javax.xml.transform.sax.SAXResult saxResult = new javax.xml.transform.sax.SAXResult( driver.getContentHandler() ); // 5. Use
RE: Does render(dom) actually work?
Thanks for all your help on this. I have Fop-0.20.1-src.tar. How can I tell
which cvs this is? I only ask because I have no inet access right now.
I did discover that render(dom) does work if I load the dom object straight
from a file instead of obtaining it as the output of an xslt transform. I
serialized both objects and their xml-content is exactly the same.
So I ran every get method that outputs a string object to compare the two
DOM objects. I also compared the docTypes of each object. The only
difference I found was for the file DOM, docType.getName()=fo:root (no
quotes), for the xslt-generated dom, docType.getName()=null (all other
docType values are null for both docTypes). I don't know whether this is
causing the problem or not. Unfortuantely DOM Level 2 doesn't support
editing DocumentType nodes.
I'm experimenting with several work-arounds right now but have had no luck.
Any ideas?
Thanks a lot,
Matt
Here is the source I'm using:
DocumentBuilderFactory dFactory =
DocumentBuilderFactory.newInstance();
dFactory.setNamespaceAware(true);
DocumentBuilder dBuilder = dFactory.newDocumentBuilder();
org.w3c.dom.Document xmlDoc = dBuilder.parse(xmlFilename);
DOMSource xmlDomSource = new DOMSource(xmlDoc);
org.w3c.dom.Document xslDoc = dBuilder.parse(xslFilename);
DOMSource xslDomSource = new DOMSource(xslDoc);
org.w3c.dom.Document foDoc = dBuilder.parse(foFilename);
DOMSource foDomSource = new DOMSource(foDoc);
DOMResult domResult = new DOMResult();
TransformerFactory tFactory = TransformerFactory.newInstance();
javax.xml.transform.Templates templates =
tFactory.newTemplates(xslDomSource);
Transformer transformer = templates.newTransformer();
transformer.transform( xmlDomSource, domResult );
org.w3c.dom.Document foOutDoc =
(org.w3c.dom.Document)domResult.getNode();
System.out.println(\foDoc:);
System.out.println(foDoc.getLocalName());
System.out.println(foDoc.getNamespaceURI());
System.out.println(foDoc.getNodeName());
System.out.println(foDoc.getNodeValue());
System.out.println(foDoc.getPrefix());
org.w3c.dom.DocumentType foDocType = foDoc.getDoctype();
System.out.println(\foDocType:);
if (foDocType != null) {
System.out.println(foDocType.getInternalSubset());
System.out.println(foDocType.getName());
System.out.println(foDocType.getPublicId());
System.out.println(foDocType.getSystemId());
}
System.out.println(\nfoOutDoc:);
System.out.println(foOutDoc.getLocalName()= +
foOutDoc.getLocalName());
System.out.println(foOutDoc.getNamespaceURI());
System.out.println(foOutDoc.getNodeName());
System.out.println(foOutDoc.getNodeValue());
System.out.println(foOutDoc.getPrefix());
org.w3c.dom.DocumentType foOutDocType = foOutDoc.getDoctype();
System.out.println(\nfoOutDocType:);
if (foOutDocType != null) {
System.out.println(foOutDocType.getInternalSubset());
System.out.println(foOutDocType.getName());
System.out.println(foOutDocType.getPublicId());
System.out.println(foOutDocType.getSystemId());
}
org.apache.fop.apps.Driver driver = new
org.apache.fop.apps.Driver();
driver.setErrorDump(true);
driver.setRenderer(driver.RENDER_PDF);
driver.setupDefaultMappings() ;
driver.setOutputStream(new FileOutputStream(pdfFilename));
System.out.println(\ndriver.render(foDoc));
driver.render(foDoc);
System.out.println(\ndriver.render(foOutDoc));
driver.render(foOutDoc);
This is the output:
foDoc:
foDoc.getLocalName()=null
foDoc.getNamespaceURI()=null
foDoc.getNodeName()=#document
foDoc.getNodeValue()=null
foDoc.getPrefix()=null
foDocType:
foDocType.getInternalSubset()=null
foDocType.getName()=fo:root
foDocType.getPublicId()=null
foDocType.getSystemId()=null
foOutDoc:
foOutDoc.getLocalName()=null
foOutDoc.getNamespaceURI()=null
foOutDoc.getNodeName()=#document
foOutDoc.getNodeValue()=null
foOutDoc.getPrefix()=null
foOutDocType:
driver.render(foDoc)
building formatting object tree
setting up fonts
[1]
[2]
Parsing of document complete, stopping renderer
Initial heap size: 1766Kb
Current heap size: 2586Kb
Total memory used: 820Kb
Memory use is indicative; no GC was performed
These figures should not be used comparatively
Total time used: 734ms
Pages rendererd: 2
Avg render time: 367ms/page
driver.render(foOutDoc)
building formatting object tree
setting up fonts
java.lang.NullPointerException
at java.util.Hashtable.get(Hashtable.java:320
Does render(dom) actually work?
Hello everyone. By any chance can someone point me to some example code which uses render(dom)? No matter what combination of driver methods or Fop versions (.17,.19,.20.1) I use I seem to get the same error: building formatting object tree setting up fonts java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:191) at org.apache.fop.tools.DocumentReader.parse(DocumentReader.java:444) at org.apache.fop.apps.Driver.render(Driver.java:449) at FOtoPDF.applyFop(FOtoPDF.java:83) at FOtoPDF.main(FOtoPDF.java:24) Here is the source I'm using under v.0.20.1: org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(org.apache.fop.apps.Driver.RENDER_PDF); driver.setOutputStream(new FileOutputStream(pdfFilename)); driver.setupDefaultMappings() ; driver.addElementMapping(org.apache.fop.fo.StandardElementMapping); driver.addElementMapping(org.apache.fop.svg.SVGElementMapping); driver.addElementMapping(org.apache.fop.extensions.ExtensionElementMapping ); driver.render(dom); I have tried it with and without any of the mapping methods. I am building the Dom object from a file. The sax input handler created from the same file works fine in render(parser, inputSource). I have read through the dev archives and found a few suggestions but none helped. Is there some configuration I'm missing? Or did this break a long time ago as someone suggested in the archives? I am hoping to use FOP in a major production app, but if I can't solve this I may not be able to. I am currently receiving a DOM object (a small report) from some database access classes. I then perform an XSLT transform which outputs my FO input as another DOM object. I suppose I could pipe the output of that to SAX? I'd really rather not have to do anything klugy like serialize it to a stream and then feed it in as SAX. But I'll consider anything that doesn't cause too much of a performace hit. We definitely don't want to have temp files sitting around, for a host of reasons. Thank you very much for your help. Matt Savino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Does render(dom) actually work?
Matt, Why don't you do it all in one pass? I have a servlet, that calls some bean to get XML document in a DOM format (actually JDOM), then registers fop driver as receiver of SAX events and runs XSLT on the JDOM tree. // 1. Generate XML tree Document xmlSummary = DataLoader.getSummary(); // 2. Get stylesheet transformer Transformer transformer = transformerFactory.getTransformer( xsl-file ); // 3. Create FOP driver and set rendering mode and output stream org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(driver.RENDER_PDF); driver.setOutputStream( out ); // 4. Create SAXResult based on FOP Driver content handler which will accept // SAX events and build FOP tree javax.xml.transform.sax.SAXResult saxResult = new javax.xml.transform.sax.SAXResult( driver.getContentHandler() ); // 5. Use the Transformer to transform an XML Source and send the output // to a Result object. // Implicitely it will create the FOP tree by firing SAX events transformer.transform( new org.jdom.transform.JDOMSource( xml ), saxResult ); YS -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 4:33 PM To: '[EMAIL PROTECTED]' Subject: Does render(dom) actually work? Hello everyone. By any chance can someone point me to some example code which uses render(dom)? No matter what combination of driver methods or Fop versions (.17,.19,.20.1) I use I seem to get the same error: building formatting object tree setting up fonts java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:191) at org.apache.fop.tools.DocumentReader.parse(DocumentReader.java:444) at org.apache.fop.apps.Driver.render(Driver.java:449) at FOtoPDF.applyFop(FOtoPDF.java:83) at FOtoPDF.main(FOtoPDF.java:24) Here is the source I'm using under v.0.20.1: org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(org.apache.fop.apps.Driver.RENDER_PDF); driver.setOutputStream(new FileOutputStream(pdfFilename)); driver.setupDefaultMappings() ; driver.addElementMapping(org.apache.fop.fo.StandardElementMapping); driver.addElementMapping(org.apache.fop.svg.SVGElementMapping); driver.addElementMapping(org.apache.fop.extensions.ExtensionElementMapping ); driver.render(dom); I have tried it with and without any of the mapping methods. I am building the Dom object from a file. The sax input handler created from the same file works fine in render(parser, inputSource). I have read through the dev archives and found a few suggestions but none helped. Is there some configuration I'm missing? Or did this break a long time ago as someone suggested in the archives? I am hoping to use FOP in a major production app, but if I can't solve this I may not be able to. I am currently receiving a DOM object (a small report) from some database access classes. I then perform an XSLT transform which outputs my FO input as another DOM object. I suppose I could pipe the output of that to SAX? I'd really rather not have to do anything klugy like serialize it to a stream and then feed it in as SAX. But I'll consider anything that doesn't cause too much of a performace hit. We definitely don't want to have temp files sitting around, for a host of reasons. Thank you very much for your help. Matt Savino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Does render(dom) actually work?
Yuri, thanks for your help. I tried your solution and I still get the following error: building formatting object tree building formatting object tree javax.xml.transform.TransformerException at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.j ava:1212) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) - java.lang.NullPointerException at org.apache.fop.fo.FOTreeBuilder.startDocument(FOTreeBuilder.java:167) at org.apache.xalan.transformer.QueuedStartDocument.flush(QueuedStartDocument.j ava:108) at org.apache.xalan.transformer.ResultTreeHandler.flushPending(ResultTreeHandle r.java:758) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHandle r.java:245) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHandle r.java:209) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java: 704) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Transform erImpl.java:2154) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Transform erImpl.java:2097) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Transformer Impl.java:2029) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.j ava:1189) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) It looks very similar to the one before to me. Has anyone tried this with v.0.20.1 yet? Should it say building formatting object tree twice? I'm wondering if this is some kind of issue with namespaces and the DOM2 implementation. Anyone have any ideas? By the way, if I use a DOMResult instead of a SAXResult I get no error. I then serialized the DOMResult to a file and FO works fine with that file as an input. Thanks, Matt -Original Message- From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 2:03 PM To: '[EMAIL PROTECTED]' Subject: RE: Does render(dom) actually work? Matt, Why don't you do it all in one pass? I have a servlet, that calls some bean to get XML document in a DOM format (actually JDOM), then registers fop driver as receiver of SAX events and runs XSLT on the JDOM tree. // 1. Generate XML tree Document xmlSummary = DataLoader.getSummary(); // 2. Get stylesheet transformer Transformer transformer = transformerFactory.getTransformer( xsl-file ); // 3. Create FOP driver and set rendering mode and output stream org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(driver.RENDER_PDF); driver.setOutputStream( out ); // 4. Create SAXResult based on FOP Driver content handler which will accept // SAX events and build FOP tree javax.xml.transform.sax.SAXResult saxResult = new javax.xml.transform.sax.SAXResult( driver.getContentHandler() ); // 5. Use the Transformer to transform an XML Source and send the output // to a Result object. // Implicitely it will create the FOP tree by firing SAX events transformer.transform( new org.jdom.transform.JDOMSource( xml ), saxResult ); YS -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 4:33 PM To: '[EMAIL PROTECTED]' Subject: Does render(dom) actually work? Hello everyone. By any chance can someone point me to some example code which uses render(dom)? No matter what combination of driver methods or Fop versions (.17,.19,.20.1) I use I seem to get the same error: building formatting object tree setting up fonts java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:191) at org.apache.fop.tools.DocumentReader.parse(DocumentReader.java:444) at org.apache.fop.apps.Driver.render(Driver.java:449) at FOtoPDF.applyFop(FOtoPDF.java:83) at FOtoPDF.main(FOtoPDF.java:24) Here is the source I'm using under v.0.20.1: org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(org.apache.fop.apps.Driver.RENDER_PDF); driver.setOutputStream(new FileOutputStream(pdfFilename)); driver.setupDefaultMappings
RE: Does render(dom) actually work?
Hi Savino, Make sure there are NO nulls making their way into the text nodes of your xml stream. these would not give problems if u wrote the xml to a file first suhail -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 3:59 AM To: '[EMAIL PROTECTED]' Subject: RE: Does render(dom) actually work? Yuri, thanks for your help. I tried your solution and I still get the following error: building formatting object tree building formatting object tree javax.xml.transform.TransformerException at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm pl.j ava:1212) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) - java.lang.NullPointerException at org.apache.fop.fo.FOTreeBuilder.startDocument(FOTreeBuilder.java:167) at org.apache.xalan.transformer.QueuedStartDocument.flush(QueuedStartDocume nt.j ava:108) at org.apache.xalan.transformer.ResultTreeHandler.flushPending(ResultTreeHa ndle r.java:758) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHa ndle r.java:245) at org.apache.xalan.transformer.ResultTreeHandler.startElement(ResultTreeHa ndle r.java:209) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.j ava: 704) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Trans form erImpl.java:2154) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Trans form erImpl.java:2097) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Transfo rmer Impl.java:2029) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm pl.j ava:1189) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 479) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.j ava: 1118) at FOtoPDF.applyFop(FOtoPDF.java:127) at FOtoPDF.main(FOtoPDF.java:40) It looks very similar to the one before to me. Has anyone tried this with v.0.20.1 yet? Should it say building formatting object tree twice? I'm wondering if this is some kind of issue with namespaces and the DOM2 implementation. Anyone have any ideas? By the way, if I use a DOMResult instead of a SAXResult I get no error. I then serialized the DOMResult to a file and FO works fine with that file as an input. Thanks, Matt -Original Message- From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 2:03 PM To: '[EMAIL PROTECTED]' Subject: RE: Does render(dom) actually work? Matt, Why don't you do it all in one pass? I have a servlet, that calls some bean to get XML document in a DOM format (actually JDOM), then registers fop driver as receiver of SAX events and runs XSLT on the JDOM tree. // 1. Generate XML tree Document xmlSummary = DataLoader.getSummary(); // 2. Get stylesheet transformer Transformer transformer = transformerFactory.getTransformer( xsl-file ); // 3. Create FOP driver and set rendering mode and output stream org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver(); driver.setRenderer(driver.RENDER_PDF); driver.setOutputStream( out ); // 4. Create SAXResult based on FOP Driver content handler which will accept // SAX events and build FOP tree javax.xml.transform.sax.SAXResult saxResult = new javax.xml.transform.sax.SAXResult( driver.getContentHandler() ); // 5. Use the Transformer to transform an XML Source and send the output // to a Result object. // Implicitely it will create the FOP tree by firing SAX events transformer.transform( new org.jdom.transform.JDOMSource( xml ), saxResult ); YS -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 4:33 PM To: '[EMAIL PROTECTED]' Subject: Does render(dom) actually work? Hello everyone. By any chance can someone point me to some example code which uses render(dom)? No matter what combination of driver methods or Fop versions (.17,.19,.20.1) I use I seem to get the same error: building formatting object tree setting up fonts java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:191) at org.apache.fop.tools.DocumentReader.parse(DocumentReader.java:444) at org.apache.fop.apps.Driver.render(Driver.java:449) at FOtoPDF.applyFop
