Thanks to the input from the honorable fop-user's and the posting
http://www.biglist.com/lists/xsl-list/archives/200212/msg00917.html I
managed to put something together.
To make the thread complete here is the Perl script to generate the XML
(again, you might has to change the first line of ta
> -Original Message-
> From: [EMAIL PROTECTED]
>
Hi,
> There are some items where I am still a bit confused.
>
> As to splitting up the table:
> J.Pietschmann wrote:
> > It's not enough to reduce memory consumption. In order to
> > reclaim memory locked up in Area objects related to the
Another option for generating PDF, if you don't need all the advanced
functionality of an XSL processor, could be iText:
http://www.lowagie.com/iText/, http://sourceforge.net/projects/itext/.
I have not worked with this product before, but it *may* be able to
handle very large and relatively
Thanks for the answers.
There are some items where I am still a bit confused.
First, I must agree that it might not make sence to render 2 rows into
PDF. The problem is, that the user can pick bad criteria and I can not
interact with him at that time.
As to splitting up the table:
J.Piet
Chris Bowditch wrote:
Is it mean , closing the and once again opening the
in the xsl file. ?
Yes, this is what I mean.
It's not enough to reduce memory consumption. In order to
reclaim memory locked up in Area objects related to the
table, the FOs itself have to be reclaimed, which only
happens a
[EMAIL PROTECTED] wrote:
Hi Chris,
What do you mean by splitting the table?
Is it mean , closing the and once again opening the
in the xsl file. ?
Yes, this is what I mean. You will need to redefine the columns for each new
table you open.
Chris
---
Pascal,
The number of rows is not a problem in alt-design, with the usual
proviso about forward references. Pages are built up as rows are
encountered. There may be other valid reasons to break up huge tables
into sub-tables, but memory consumption will not be one of them.
Peter
Pascal Sancho
s Bowditch [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 09, 2004 7:16 PM
To: [EMAIL PROTECTED]
Subject: Re: OutOfMemoryError by large tables: Alternative solution?
[EMAIL PROTECTED] wrote:
>
>
>
> Greetings,
>
> I have a XML file containing data to be formatted as table row
ter B. West [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 10 juin 2004 11:32
À : [EMAIL PROTECTED]
Objet : Re: OutOfMemoryError by large tables: Alternative solution?
I would like to answer this question now by saying, "Alt-design".
However, I cannot - yet. The layout work has just begun
I would like to answer this question now by saying, "Alt-design".
However, I cannot - yet. The layout work has just begun, and is aiming
initially at a Java 2D solution. When that is complete, unless someone
cares to work in parallel on PDF rendering from the Java 2D
representation, that PDF
Chris Bowditch wrote:
Splitting the table up is the best way to reduce the ratio
memory:input size. Also, there have been some tweaks made to the
maintenance code in CVS that help improve the memory usage of tables.
To use this latest code, you will need to install a CVS client,
download the 0.
[EMAIL PROTECTED] wrote:
Greetings,
I have a XML file containing data to be formatted as table rows. The number
of rows will exceed 1. As the FOP processes the data the "Exception in
thread "main" java.lang.OutOfMemoryError" occurs.
As I've seen in the discussion forums, one possibi
[EMAIL PROTECTED] wrote:
Greetings,
I have a XML file containing data to be formatted as table rows. The number
of rows will exceed 1. As the FOP processes the data the "Exception in
thread "main" java.lang.OutOfMemoryError" occurs.
This is a common problem.
As I've seen in the discussion foru
Greetings,
I have a XML file containing data to be formatted as table rows. The number
of rows will exceed 1. As the FOP processes the data the "Exception in
thread "main" java.lang.OutOfMemoryError" occurs.
As I've seen in the discussion forums, one possibility is to increase the
memory
14 matches
Mail list logo
