Re: Problems with SAX pipeline
Hi David, David B. Bitton wrote: my code uses the following: transformer.transform( new DOMSource( doc ), new SAXResult( _driver.getContentHandler() )); and it works great. Lemme know if you'd like to see the rest. :) My code is exactly the same: transformer.transform(new JDOMSource(result.getDocument()), new SAXResult(driver.getContentHandler())); If I replace the SAXResult by a StreamResult to a file and run FOP on this file, the PDF document is OK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with SAX pipeline
Hi again, J.Pietschmann wrote: I suggest to check your SAX stream first whether all elements are properly closed. Try to feed it as a SAXSource to an identity XSL transformation (use TransformerFactory.newInstance().newTransformer()). The serialized file will be always well-formed (the transformer closes open elements for you) but you could check for suspicious omissions at the end. I did what you suggest and also tried with Megginson's XMLWriter. In both cases, the original XML document (before XSLT transformation) and the FO document look OK (Megginson's writer does not alter/fix the SAX event stream.) I compared the debug traces generated by FOP in command-line mode and embedded mode, they're exactly the same. I remove the setting of namespace-prefixes in Starter.java. No change except that FOP can now run with Saxon! At least this is good news!!! Finally I removed all refences to external graphics, thinking it may be a problem of URI resolution: The PDF is smaller but Acrobat still complains the same! Can you think of any place in the code where I could set a breakpoint/trace to get more information about what's going on? TIA Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with SAX pipeline
Laurent Bihanic wrote: FOP does not display any error message but the generated PDF file is 2 KB shorter than when generated from the same FO document read from a file and Acrobat Reader complains that the file is damaged and could not be repaired. I found the problem in the application's code (flush() was called on a raw OutputStream while a BufferedOutputStream was passed to FOP). Sorry about the disturbance. Yet, if FOP no longer requires setting namespace-prefixes set to true, it would be nice to update Starter.java so that FOP could be used with Saxon. Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Problems with SAX pipeline
Hi, I'm in the process of migrating an application from FOP 0.17 to 0.20.3. This application uses a SAX pipeline to apply an XSLT transformation (XML - XSL-FO) and feed it into FOP's Driver directly through its ContentHandler. FOP does not display any error message but the generated PDF file is 2 KB shorter than when generated from the same FO document read from a file and Acrobat Reader complains that the file is damaged and could not be repaired. Is this a known bug ? (I had a look at both FOPServlet and XSLTInputHandler and realized the latter does not use a SAX pipeline but stores the FO document in a temporary file or buffer before returning it to the former.) I had a look at FOP's code to try to find a fix and came up with the following question: Why does Starter set the SAX feature http://xml.org/sax/features/namespace-prefixes; to true in method setParserFeature ? Using this feature makes the SAX event stream received from a SAX parser different from the one received from an XSLT processor. Apparently, FOTreeBuilder does not care about this feature as it uses the Namespace URI and the local name to look-up the maker objects. But maybe other classes do care. Can this namespace prefix thing be related to my problem ? Is the use of namespace prefixes required for FOP ? Can this be fixed so that output from XSLT processors be acceptable as SAX input ? TIA, Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with SAX pipeline
Laurent Bihanic wrote: This application uses a SAX pipeline to apply an XSLT transformation (XML - XSL-FO) and feed it into FOP's Driver directly through its ContentHandler. FOP does not display any error message but the generated PDF file is 2 KB shorter than when generated from the same FO document read from a file and Acrobat Reader complains that the file is damaged and could not be repaired. No. I suggest to check your SAX stream first whether all elements are properly closed. Try to feed it as a SAXSource to an identity XSL transformation (use TransformerFactory.newInstance().newTransformer()). The serialized file will be always well-formed (the transformer closes open elements for you) but you could check for suspicious omissions at the end. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with SAX pipeline
my code uses the following: transformer.transform( new DOMSource( doc ), new SAXResult( _driver.getContentHandler() )); and it works great. Lemme know if you'd like to see the rest. :) -- David B. Bitton [EMAIL PROTECTED] www.codenoevil.com Code Made Fresh DailyT - Original Message - From: J.Pietschmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 4:16 PM Subject: Re: Problems with SAX pipeline Laurent Bihanic wrote: This application uses a SAX pipeline to apply an XSLT transformation (XML - XSL-FO) and feed it into FOP's Driver directly through its ContentHandler. FOP does not display any error message but the generated PDF file is 2 KB shorter than when generated from the same FO document read from a file and Acrobat Reader complains that the file is damaged and could not be repaired. No. I suggest to check your SAX stream first whether all elements are properly closed. Try to feed it as a SAXSource to an identity XSL transformation (use TransformerFactory.newInstance().newTransformer()). The serialized file will be always well-formed (the transformer closes open elements for you) but you could check for suspicious omissions at the end. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
