https://issues.apache.org/bugzilla/show_bug.cgi?id=51210
Andreas L. Delmelle <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE OS/Version| |All --- Comment #1 from Andreas L. Delmelle <[email protected]> 2011-05-24 21:45:50 UTC --- (In reply to comment #0) > During the long period of PDF transformation we noticed that the destination > *.pdf file is not increasing in size but stays at 0 KB! Therefore, it seems > that FOP/Transform is trying to generate the PDF completely in RAM!? Yes and no. The entire content would only be in memory if any of the following conditions are met: * all content is placed inside a single fo:page-sequence * the document contains forward references to the last fo:page-sequence (typically: "page x of y" requirements, or TOCs at the start of a huge document) The former can currently only be resolved by splitting up the input, which means altering the stylesheet code, and an unavoidable trade-off of a forced page break, but is considered better practice anyway. A monolithic page-sequence (as its correlate: paragraph) is a typographical monstrosity. The impact of the latter can be reduced by calling foUserAgent.setConserveMemoryPolicy(true);. That will result in finished pages with unresolved references being serialized to disk. In other cases, if a page-sequence can be rendered, it will be. I am not 100% sure, but I even think that, if the output stream can be written to disk, it will be. Ultimately, that is also a decision of the JVM/OS. Marking this as a duplicate of bug #1063. Until that is resolved: see above. *** This bug has been marked as a duplicate of bug 1063 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
