xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
Date Wed, 18 May 2011 18:45:18 GMT

--- Comment #3 from Andreas L. Delmelle <adelmelle@apache.org> 2011-05-18 18:45:18 UTC
(In reply to comment #0)
> 1. FOP Performs unusually SLOW if there is a large paragraph
> We have noticed that when there is an unusually large paragraph than FOP
> performance is incredibly slow. FOP takes more than 15 minutes in the method
> findBreakingPoints which is defined in BreakingAlgorithm.java. The paragraph
> size is of around 50 thousand characters. This method seems to find the best
> possible Break point. Can we not make this method return a default break point
> that works for the English language ?

Sorry, I do not understand the point you are trying to make here. 
What is 'unusual' is having a paragraph with 50K chars in the first place, and
then expecting an advanced layout algorithm to just process this as fast as one
with only 500 chars.

Admittedly, FOP has a scalability problem here, but 50K chars? Really? Who is
supposed to read that?

Could it be that the paragraph is pre-formatted, perhaps? That is: Does it
contain linefeeds that may be preserved? In that case, specify
linefeed-treatment="preserve" on the surrounding block and it will go
significantly faster.

> 2. FOP uses unusually large memory when running in findBreakingPoints method
> defined in BreakingAlgorithm.java. This method starts to consume around 500 MB
> memory creating thousands of Objects of KnuthNode type. Such memory consumption
> is unacceptable just for finding a line break :-(.

It is not 'finding a line-break'. It determines the most optimal line-breakS

And again: we know of this issue, but fixing it is non-trivial, unfortunately.

> Is there a way, I can prevent this extensive memory usage and slow performance
> by using a default break ?

You can, as suggested above, make sure the linefeeds are preserved, if that is
what you mean by 'default break'. Each line will then become a sub-paragraph,
and the complete paragraph will take only a fraction of the time and memory to

The only other option is to split that monster-paragraph into smaller ones.
Divide and conquer.

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

View raw message