You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Laurent Bihanic <la...@atosorigin.com> on 2002/03/26 18:17:59 UTC

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Problems with SAX pipeline

Posted by Laurent Bihanic <la...@atosorigin.com>.

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Problems with SAX pipeline

Posted by Laurent Bihanic <la...@atosorigin.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Problems with SAX pipeline

Posted by Laurent Bihanic <la...@atosorigin.com>.
Hi,

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.
> 
My SAX source is the output of an XSLT processor:
   transformer.transform(new JDOMSource(result.getDocument()),
                         new SAXResult(driver.getContentHandler()));

If I redirect the XSLT output to a file (using a StreamResult), FOP can 
successfully process it.
Anyway, I'll try what you suggest and check the generated FO file.

TIA

Laurent


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Problems with SAX pipeline

Posted by Laurent Bihanic <la...@atosorigin.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Problems with SAX pipeline

Posted by "David B. Bitton" <da...@codenoevil.com>.
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
david@codenoevil.com
www.codenoevil.com

Code Made Fresh DailyT
----- Original Message -----
From: "J.Pietschmann" <j3...@yahoo.de>
To: <fo...@xml.apache.org>
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: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Problems with SAX pipeline

Posted by "J.Pietschmann" <j3...@yahoo.de>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org