Hello all. First time poster. I'm being plagued by memory issues with this one
report that uses FOP to render PDFs. What happens is the user (my boss in
this case) takes some criteria which generates what we consider an average
result set. We transofrm the results into XML and I've coded an XSL-
Title: RE: Rép. : RE: Rép. : xsltc trax transformer problems
Thanks a lot - we have some progress!!
That proved really helpful, I think
I passed in my XML document and my xsl:fo, and this is the error message:
Exception in thread "main" java.lang.ClassFormatError: translet_out (Code
Thanks for the quick reply!
I've suspected that too, but since I haven't gotten any parser errors, I
haven't checked that out too much.
The problem is when I create a test app, I get an exception, 'could not
instantiate translet 'GregorSamsa' I believe I've included all the jars Trax
specifies
Find below a batch script which I use to call xsltc processor for testing.
It is for Windows but for a Unix it would be similar.
@echo off
REM Script pour l'appel du processur XSLTC en ligne de commande
REM Les librairies XSLTC doivent être soit dans le classpath ou dans le
rép
Hi,
Maybe your problem is aound xalan and not FOP. But we had similar issues
when we switch from xslt to xsltc. xsltc is a bit more sensitive but
often the issue is a "bug" into xsl.
My advice is:
- Test and migrate your xsl using Xalan xsltc only and then use fop.
Concerning Weblogic, I noted i
Hi All
I’m getting a really confusing error when trying to generate a standard PDF
file.
When I’m using the exact same XML and XSL:FO with two different transformers I
get what I want with one (standard xalan transformer) but with the other (xalan
xsltc.trax transformer) FOP just hangs and
Hi All
I’m getting a really confusing error when
trying to generate a standard PDF file.
When I’m using the exact same XML and XSL:FO with
two different transformers I get what I want with one (standard xalan
transformer) but with the other (xalan xsltc.trax transformer) FOP just ha
Craig McDaniel wrote:
Well, the FileReader is reading into a String and then it is converted
to a byte array using getBytes(). I know, its weird, but I'm not the
original author of this code and its my job to "fix" it.
That's likely to be the cause of the encoding problem. There's an
implicit
Title: Nachricht
Thanks, I will give it a try.
We are pre-generating the FO using RTFtoFO. Do you think that parsing is
the bottleneck ?
Actually I do some preprocesssing using a DOM tree of the same FO and
this is pretty fast, so there seems something else going on.
Are there any
hints