(In reply to comment #0)
> I am currently having problem compiling a 420 page document, with about 50
> figures. The problem sees to be memory related, however the debugging
> information is insufficient for me to identify the problem.
> 
> Using th fop ant task, I get
> 
>   Exception in thread "main" java.lang.NoSuchMethodError: main
> 
> When using the commandline tool, the a bit more infomation is released, such as
> 
> WARNING: Line 1 of a paragraph overflows the available area. (fo:block,
> location: 4794/406)
> Exception in thread "main" java.lang.OutOfMemoryError
> 
> Note, this document compiled just fine with FOP 0.20.5

It's normal, FOP 0.92 beta needs more memory because it cheks much more the
XSL-FO format than the FOP 0.20.5 was doing. 
So just enables more memory to the JVM and it will be ok.

It could also be that something is now detected as wrong because of the new
test, but it wouldn't be this error message, I think.

Ok, that sounds reasonable.

I have constantly read statements, which claimed Trunk was able to process much
larger documents, which I also interpreted as a much smaller memory food print.

(In reply to comment #2)
> I have constantly read statements, which claimed Trunk was able to process much
> larger documents, which I also interpreted as a much smaller memory food print.

It's not that simple, I'm afraid... 
Although most reports we have received so far indeed indicate that 0.9x is generally faster and uses less 
resources, this greatly depends greatly on the structure of your FO document. 
The use of multiple, relatively small page-sequences is a key factor here. If a document is divided nicely 
into sequences of 10 pages maximum, then the total number of pages becomes irrelevant. We've had 
feedback from users processing 12000 paged documents without complaints (although the heap still 
grows to about 0.5GB).

Forgot to mention: dividing into page-sequences offers only marginal improvement (if not none at all) 
when using forward references to the end of the document...

I am a longer list of documents and the way fop is used depends upon the memory
requirements of the individual document.

By default, I use the fop ant task, but when there are specific memory
requirements that is not possible (since the ant task does not have a maxmemory
attribute like the ant java task - IT SHOULD).

For these documents, I instead use the ant task

  <java class="" maxmemory="200M" ...>

In in 0.20.5 the class name was  org.apache.fop.apps.Fop

That does not work in 0.93, where one should use the class

   org.apache.fop.cli.Main

That change in the API should be listed in docs/0.93/upgrading.html

(In reply to comment #5)
> In in 0.20.5 the class name was  org.apache.fop.apps.Fop
> 
> That does not work in 0.93, where one should use the class
> 
>    org.apache.fop.cli.Main
> 
> That change in the API should be listed in docs/0.93/upgrading.html

I documented that for future releases (too late for 0.93).

(In reply to comment #5)
> By default, I use the fop ant task, but when there are specific memory
> requirements that is not possible (since the ant task does not have a maxmemory
> attribute like the ant java task).
> 
> For these documents, I instead use the ant task
> 
>   <java class="" maxmemory="200M" ...>

maxmemory works only when one forks. Your solution to use the java task seems
fine. Then there is no need to add capabilities to the fop task. We may add this
to the anttask documentation page.

increase RAM size as necessary

batch transition resolved+wontfix to closed+wontfix

batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen