xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Stuermer <jstuer...@lrn.com>
Subject RE: PDF Forms
Date Tue, 03 Feb 2004 23:54:44 GMT
I'm not sure what could cause this relatively slow performance. I'm not an
expert on FOP, I can only talk about my experience using it.

It can't be the hardware or the app server that make the difference because
I'm using JDK 1.3.1 on Windows2000 (PIII600, 256MB) on my dev box to run FOP
from the command line and I'm getting essentially the same performance as on
the Linux box, which has more memory and throughput.
At run-time, I'm following the tips on improving performance documented at:

If you are getting the same slow performance by running FOP from the command
line, I'm guessing the performance hit occurs because of the composition of
the FO file. There are some good suggestion on the apache/fop site, such as
http://xml.apache.org/fop/running.html#memory but I think your best bet is
to do a few simple benchmark tests on your system with FO files of different
degrees of complexity. Start with an extremely simple FO file with a few
dozen pages, measure the rendering time and then increase the complexity
step by step while you keep the page count constant. This should tell you
where you get the performance hit.
In my experience, an FO file of medium complexity, example: a two column and
header/footer layout with several nested tables, a few jpg/gif images
(together <50k for each page), but no vector graphics should process at 5 -
10 pages per second. If you are not an FO expert, I would avoid hand-crafted
FO files for this test. Rather use something like XMLSpy to create the FO

I hope this helps.

-----Original Message-----
From: Chris Pratt [mailto:chrisp@planetpratt.com]
Sent: Tuesday, February 03, 2004 2:38 PM
To: fop-user@xml.apache.org
Subject: Re: PDF Forms

Johannes Stuermer wrote:
> If your data source are xml documents, one way to streamline this process
> would be to use a stylesheet editor such as XMLSpy to automatically
> the XSL-FO file that can then be consumed by a simple XSL-FO>FO>PDF
> using FOP. If you need to personalize the PDF at run-time, you can
> manipulate the xml source file before you transform it using XSL-FO.
> I'm generating large and complex PDF documents (100-300) pages in 10 - 30
> seconds using a single Linux box running a J2EE app server.

I'd like to understand what could be so different between our two apps.  I
am running FOP 0.20.5 on Sun JDK 1.4.2_03 on Windows NT.  When I run our
largest document, (125 pages) through fop on the command line, it pegs the
processor at 100%, takes 156MB of heap and takes 1 minute 15 seconds to
finish.  If I just had to run one of these, once in a while it wouldn't be a
problem, but this has to be dynamically generated by a servlet and returned
to the user in real time and when it pegs the processor and takes up much of
the heap allocated to the VM it causes problems with all the other users of
the system.  Is there anything anyone can think of that might cause such a
massive difference in the time it takes to produce large documents?  Any
help would be massively appreciated.

> -----Original Message-----
> From: Chris Pratt [mailto:chrisp@planetpratt.com]
> Sent: Tuesday, February 03, 2004 11:34 AM
> To: fop-user@xml.apache.org
> Subject: PDF Forms
> I'm using FOP 0.20.5 and I've coded myself into a corner.  We generate
> rather large PDF files using fop (lists of every eye doctor in California
> for example), which can be very processor and very memory intensive.  To
> limit the overhead I wrote a caching scheme that caches the complete PDF
> files for easy re-use.  Worked really well until the powers that be
> that each of the PDF's needed to be personalized.
> Looking around for an alternative to just removing the caching, I found
> Forms which would probably do the job.  I don't expect that FOP has any
> ability to fill in forms of already generated PDF Forms, but I was hoping
> that it might have the ability to generate them.  Does anyone have a clue
> how I might go about this?  Or maybe an altogether better way of solving
> problem?  Thanks.
>   (*Chris*)

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

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

View raw message