xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Georg Datterl" <georg.datt...@geneon.de>
Subject AW: page-sequence and out-of-memory
Date Mon, 25 May 2009 06:55:36 GMT
Hi Ben, 

Well, I have one idea, but I'm not sure you can use it. You'll have to use the area tree.

* You want to to print 10 pages in one page sequence, for example.
* Guess, how many rows you will need to fill these 10 pages. Add some to make sure, the 10
pages are always filled.
* Give each row an id. Keep it bidirectional, so you can find the row from the id.
* Get the area tree, ask it for the first row id of page 11.
* Print the 10 pages again, only fill it with exactly enough rows. 
* Continue with next batch. Keep in mind, ids must be unique in document, so either you removed
the ids from the previous batch or the id contains a batch identifier.

Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert 

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH:    www.irs-nbg.de 
Willmy PrintMedia GmbH:                            www.willmy.de
Willmy Consult & Content GmbH:                 www.willmycc.de 
-----Ursprüngliche Nachricht-----
Von: Ben Wuest [mailto:ben.wuest@Q1Labs.com] 
Gesendet: Freitag, 22. Mai 2009 15:18
An: fop-users@xmlgraphics.apache.org
Betreff: page-sequence and out-of-memory

Hi -


I've read an incredible amount about this and do not think there is anyway around this problem
but I figured I'd send this out there to see if there were any ideas.  


The basic just of the problem is that I am trying to render a report with tabular data and
running out of memory.  The number of rows can reach 40,000 records.  From what I've read,
I understand that the reason FOP is running out of memory is because the whole table is wrapped
in one page sequence (basically a lot of pages).  


Because the fo file for the reports I am generating is generated dynamically, I was able to
batch the table into multiple page sequences (this removed the memory issues) but this presents
a problem because FOP automatically starts a new page when you end a page sequence.  This
can make the table look choppy because it can be broken with only two records on a page. 
I tried to work in algorithms to automatically estimate the batch size for a table but this
is hard because there is no real way to estimate the record height in the table or access
the current page number during the rendering process to dynamically break page sequences.


I would really like to find a way to either keep FOP's memory in check (but I don't think
I can do that without multiple page-sequences) or have a new page-sequence not automatically
start a new page.  The problem with the page sequences is that it starts a new page (so the
table is broken up).  Because the tabular data I am rendering comes in many shapes and forms
this is really not an option.  


Any ideas? 




Ben Wuest
Software Engineer, Development
Q1 Labs Inc - The Nexus of Security and Networking
Office: (506)-462-9117 ext 163 Fax: (506)-459-7016 ben.wuest@q1labs.com | http://www.q1labs.com


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

View raw message