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.