xsl-list
[Top] [All Lists]

Re: [xsl] FOP : consumption memory

2014-08-16 07:00:05
Jean-Pierre,

You may be better off asking these questions on the FOP Users list.  See Apache 
FOP for details.

Peter West

"Is not this the carpenter's son?"

On 16 Aug 2014, at 9:54 pm, Jean-Pierre Lamon jpl(_at_)ngscan(_dot_)com 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

Hi,
 
I’m not a FOP expert too and more… don’t know quite nothing about Javat. The 
problem I see in this approach is keeping the link for the pagination. 
My poor FOP skills doesn’t give me the answer.
So, is this approach feasible? Pagination is “obligatory”.
 
Cheers
JP
De : Imsieke, Gerrit, le-tex gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de 
[mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com] 
Envoyé : samedi 16 août 2014 13:39
À : xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Objet : Re: [xsl] FOP : consumption memory
 
I’m not a FOP expert, but can’t you separate the pass(es) that generate the 
index, resolve cross-refs, etc., from the pass that actually layouts the FO 
representation? By separate I mean make it separate Java invocations, storing 
intermediate results as files.


On August 16, 2014 1:04:46 PM CEST, "Eliot Kimber 
ekimber(_at_)contrext(_dot_)com" 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
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


—————


Eliot Kimber, Owner


Contrext, LLC


http://contrext.com









On 8/16/14, 2:26 AM, "Jean-Pierre Lamon 
jpl(_at_)ngscan(_dot_)com"

<
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_at_)contrext(_dot_)com

[
mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com]

Envoyé : vendredi 15 août 2014 23:44


À : 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


—————


Eliot Kimber, Owner


Contrext, LLC


http://contrext.com









On 8/15/14, 1:32 PM, "Jean-Pierre Lamon 
jpl(_at_)ngscan(_dot_)com"

<
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_at_)gbormans(_dot_)telenet(_dot_)be

[
mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com]

Envoyé : vendredi 15 août 2014 17:12


À : 
xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com

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.


I’ve tried to play with JAVA memory etc… no way.




Thanks and regards


JP




<
http://www.mulberrytech..com/xsl/xsl-list>XSL-List info and archive

<-list/554170>EasyUnsubscribe


(<>by email)

 




--~









XSL-List info and archive: 
http://www.mulberrytech..com/xsl/xsl-list

EasyUnsubscribe: 
by email)
 
 
XSL-List info and archive
EasyUnsubscribe (by email)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>