Although a bit late I want to share the following response I got from renderX with you.
I explained my problem to them (XEP wouldn't even begin processing my doc) and I got this for an answer.


<---
==================================================
begin of message
==================================================
-->
Thanks for contacting us.
Please, find below the answers to your
technical questions, provided by our support team.

> It doesn't seem to get beyond the parse message.
> The fo document is 14mb, and that would be about 400 pages.
>
> We run this on a pII 333mhz 196mb machine with a 850 swapfile.
We suspect that this document is too big for XEP on this machine, too.
You probably know that XEP stores the full document in memory. 196 MB
of RAM mean ca 140-150 MB of physical memory available for Java heap;
this is definitely not enough to host the full parsing tree of a 14 MB
document.
And when Java hits the swap limit, it becomes terribly slow: if you compare
CPU time to user time, you can find values of 1-2-3%.
The only way to format such a monster document is to increase RAM to 512
or even 1024 MB. Note that processing time will be around half an hour
in any case.
As for the "parse:" message: on large documents, this phase may take up
to 30% of the whole processing phase. So it's no wonder that the system
seems to hang: several minutes may pass before you see pages ticking.

> What can be done?
Not much, indeed. You are really at the limit of XEP's applicability.
The best thing would be to split the document into three or four parts
of 100-150 pages each...
<---
==================================================
end of message
==================================================
-->
Monster document?? 400 pages?? hardly, but I confess we use a lot of tables.
If this is true for FO renderers (written in java) in general , then I will have a hard time convincing customers of ours to get into the FO scene, at least while making use of java fo renderers.




Reply via email to