Subject: Re: [xsl] FOP : consumption memory From: "Eliot Kimber ekimber@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Sat, 16 Aug 2014 17:12:03 -0000 |
Are you able to increase the amount of memory available to the Java process? E.g.: java -Xmx2G ... To git it 2Gb of RAM. If you are running on a 64-bit machine you should be able to give it up to physical RAM. On a 32-bit machine you are limited to about 1.6GB. If it's simply a memory limit then increasing the memory should solve the problem, assuming it's not a bug that uses infinite memory. Cheers, Eliot bbbbb Eliot Kimber, Owner Contrext, LLC http://contrext.com On 8/16/14, 12:00 PM, "Jean-Pierre Lamon jpl@xxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: >I've tried to break for each main chapter: > >Exception in thread "main" java.lang.OutOfMemoryError: Java heap space > at >org.apache.fop.layoutmgr.inline.TextLayoutManager$TextAreaBuilder.initWord >(T >extLayoutManager.java:612) > >JP > >-----Message d'origine----- >De : Eliot Kimber ekimber@xxxxxxxxxxxx >[mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx] >EnvoyC) : samedi 16 aoC;t 2014 13:05 >C : xsl-list >Objet : Re: [xsl] FOP : consumption memory > >I see: the two-column layout means there are no natural breakpoints in the >content before the index. The index has break points but by then it might >be too late. The back-of-the-book index could also be contributing--it's >quite long and FOP may need to keep the entire area tree in memory in >order to then resolve the index references. > >As Peter says, I would suspect a naive implementation on FOP's part (I >haven't looked at the code). Would be useful to try both RenderX XEP and >Antenna House XSL Formatter--I'm sure they would both do better. If your >project can bear the cost, either product would be a good investment. > >Cheers, > >Eliot >BBBBB >Eliot Kimber, Owner >Contrext, LLC >http://contrext.com > > > > >On 8/16/14, 2:26 AM, "Jean-Pierre Lamon jpl@xxxxxxxxxx" ><xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > >>Thank you for your response Eliot. >>I don't know if I can share these files, I must ask the principal because >>it's a mandate. >> >>The result is under : >>http://www.ngscan.com/ezpump/BibVS.pdf >> >>I'll let you know >>Regards >>JP >> >>-----Message d'origine----- >>De : Eliot Kimber ekimber@xxxxxxxxxxxx >>[mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx] >>EnvoyC) : vendredi 15 aoC;t 2014 23:44 >>C : xsl-list >>Objet : Re: [xsl] FOP : consumption memory >> >>If your content has natural page breaks (meaning elements that always >>start a new page) you can always start a new page sequence at that point. >> >>If your content does not have such nature page breaks then of course you >>can't. In that case, one solution would be to generate the intermediate >>area tree (a feature of FOP and all the other FO engines) and then use it >>to find elements that happen to start on new pages and regenerate the FO >>with page sequences started at those points. But that seems like rather a >>lot of effort. >> >>It might be easier to just give the Java VM running FOP more memory. >> >>If this is XML that can be shared publicly I'd be interested in helping >>diagnose this issue in exchange for the ability to use the XML for demos. >> >>Cheers, >> >>Eliot >>BBBBB >>Eliot Kimber, Owner >>Contrext, LLC >>http://contrext.com >> >> >> >> >>On 8/15/14, 1:32 PM, "Jean-Pierre Lamon jpl@xxxxxxxxxx" >><xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> >>>Thx Geert but I can't spread and break pages. It's a bibliography (swiss >>>national library bibliography). >>>If someone wants the XML and XSL to test, no problem :-) I'm not very >>>professional with XSL, I maybe have done some horrors in my stylesheets >>>but >>>my question is only : why FOP hangs and the little tool works perfectly. >>>With absolute respect for people working for free tools like FOP. >>> >>>-----Message d'origine----- >>>De : Geert Bormans geert@xxxxxxxxxxxxxxxxxxx >>>[mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx] >>>EnvoyC) : vendredi 15 aoC;t 2014 17:12 >>>C : xsl-list@xxxxxxxxxxxxxxxxxxxxxx >>>Objet : Re: [xsl] FOP : consumption memory >>> >>>Hi, >>> >>>In my experience FOP does a poor thing with long page sequences. >>>It seems to keep them in memory (for repagination maybe?) completely >>>Memory footprint for FOP goes down dramatically >>>if you have a logic that cuts the pages >>>Rather than using mechanisms such as break before >>>or similar, create new page sequences when you can >>>(eg. per chapter, ...) >>>That has helped me in the past >>> >>>Cheers >>> >>>Geert >>> >>> >>>At 16:33 15/08/2014, you wrote: >>>>Hi All, >>>> >>>>I know, difficult to say without having the >>>>source, but could someone explain me why FOP >>>>crashes, hangs (memory ?) for relative big >>>>documents and a free small tool like XML2PDF >>>>render the PDF perfectly and this, dramatically quicker compare to FOP. >>>>IBve tried to play with JAVA memory etcB no way. >>>> >>>>Thanks and regards >>>>JP >>>> >>>><http://www.mulberrytech.com/xsl/xsl-list>XSL-List info and archive >>>><-list/554170>EasyUnsubscribe >>>>(<>by email)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] FOP : consumption memory, Jean-Pierre Lamon jp | Thread | Re: [xsl] FOP : consumption memory, Jean-Pierre Lamon jp |
Re: [xsl] FOP : consumption memory, Jean-Pierre Lamon jp | Date | Re: [xsl] FOP : consumption memory, Jean-Pierre Lamon jp |
Month |