*Maybe* it is related to the version of the parsers used (that are
determined at runtime)... for example I've noticed that in the FOP
distribution there is a Apache Xalan-J (JAXP-compliant XSLT and XPath
implementation), but not in OFBiz, and so I guess we are using the
default JAXP implementation delivered by the JDK.
But I could be totally wrong...
Jacopo
Adrian Crum wrote:
Jacopo and Christian,
Thank you very much for your tips! I have already explored the Apache
FOP website and read the information about memory.
Here is what I have done so far:
I confirmed the code in the ScreenFop view handler is correct - it's
nearly an exact copy of the recommended code from the FOP website. I
increased memory - min 512MB, max 1024MB (2 GB RAM in PC). I re-wrote
the view handler to render to a temporary file instead of a String. I
used buffered streams wherever possible. After all of that, nothing has
changed. My next step is to reverse engineer the command line FOP to see
how it does things - maybe I can spot a difference between it and the
embedded code.
To restate the problem: the FO xml file is about 13MB in size and
converts to a 3MB PDF file in a few seconds using command-line FOP. When
the same xml file is converted in OFBiz it runs for over an hour until I
finally shut it down - no PDF file is produced.
-Adrian
Christian Geisert wrote:
Adrian Crum schrieb:
I'm having trouble using the ScreenFop view handler.
I'm trying to get the Entity Reference Chart to output to PDF. I created
a Freemarker template that generates the correct output. I set up a view
handler:
[..]
So, the individual elements all work fine, but for some reason the
screenfop view handler gets hung up.
Any ideas?
Sounds like a memory issue
(See http://xmlgraphics.apache.org/fop/trunk/running.html#memory for
some info on how to fix this)
If you send me a patch (or commit it) I'll be happy to have a look at it
