Ted,
No idea whether this is practical for your case nor whether it would
actually make a difference, but you could try a two step approach
First render the 12000 entries to pdf (a 'page' for each entry), then
use a second fo stylesheet that refers to the pdf pages as external
graphics. See http://www.jeremias-maerki.ch/development/fop/ on how to
use pdf (pages) as external graphics. If you are lucky fop will use
pdf xobjects for each of the pdf pages and include them only once.
Perhaps it helps,
Peter
On 18 May 2008, at 06:10, Ted Young wrote:
Greetings to the list,
I am using FOP version 0 .94 under Java 1.6 update 6.
I am using FOP to create a PDF dictionary from a source XML file.
There are only 12,000 entries in this dictionary. The tricky bit is
that the words being defined are in Ancient Egyptian Hieroglyphs.
Each word (or phrase) is stored in SVG format. So ultimately my FO
document contains 12,000 instream-foreign-object tags each
containing SVG. This configuration alone taxes the 1 GB memory
limit I am able to give to my virtual machine (a known issue with
running Java under Windows).
Each dictionary entry would like to contain zero or more alternative
words and phrases (think thesaurus). This increases the number of
instream-foreign-object tags containing SVG to the order of 30,000
or 40,000. Even breaking this up into individual chapters I have a
very hard time rendering these documents. They consume vast amounts
of memory and bring my system to a halt even under Linux.
So I was wondering if anyone had any suggestions on how I could
optimize my FO document and use of SVG. Since all of the "see also"
words and phrases can be found elsewhere in my document is there a
way to generate a PDF-layer reference to content located at another
part of a document? I am thinking of something analogous to symbols
in Flash; a way of having FOP render the SVG word or phrase once and
have it instruct the PDF to reuse that content in many locations.
Converting these to images is less than ideal since ancient Egyptian
hieroglyphs contain a lot of fine detail that would be lost or
blurred if rasterized. One of my main reasons for choosing this
approach was that I knew FOP would preserve the hieroglyphs in
vector format.
For what it is worth without the SVG content FOP runs
fantastically. So this seems to be due to the sheer volume of
vector data added to the rendering process by the inclusion of all
of these SVG elements.
Since this is my first time ever mailing and FOP related mailing
list when they take this opportunity to say that I have been using
FOP for over seven years now and have enjoyed every minute of it.
This is a fantastic product and I think the improvements in this new
branch in performance and API are nothing less than spectacular!
Thank you to everyone contributing to this project.
Ted young
