DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #11 from Luis Bernardo lmpmberna...@gmail.com 2012-04-24 08:40:44 UTC --- this is an outofmemory issue so what does not work in one machine may work in some other. you only see the issue if your machine runs out of memory in which case you see the usual outofmemory error/exception. when that happens there is no output PDF. any very long paragraph of non self repeating content should work as an example. self repeating a short sentence to create a long paragraph is not a good example since the line breaking algorithm may break lines always in the same place. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #12 from Luis Bernardo lmpmberna...@gmail.com 2012-04-24 08:45:26 UTC --- Created attachment 28665 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28665 example repeat the content inside the block (it is long enough to not trigger a simple line breaking solution) enough times until you see the problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WONTFIX --- Comment #13 from Glenn Adams gad...@apache.org 2012-04-24 13:19:50 UTC --- this is a resource (memory) issue, not a bug; if someone wishes to post a patch that redesigns the line breaker to operate more efficiently, then it will be given serious consideration; -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #10 from Glenn Adams gad...@apache.org 2012-04-24 05:42:25 UTC --- (In reply to comment #9) please provide minimal input FO test file, output PDF file(s), and full console output that demonstrates problem Abhijeet, I am still awaiting your input as requested above. if I see no further input by April 30, I will close this bug due to lack of requested information. Regards, Glenn -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 taffy-tyler6...@hotmail.co.uk changed: What|Removed |Added CC||taffy-tyler6...@hotmail.co. ||uk -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #9 from Glenn Adams gl...@skynav.com 2012-04-08 05:17:27 UTC --- please provide minimal input FO test file, output PDF file(s), and full console output that demonstrates problem -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 Glenn Adams gl...@skynav.com changed: What|Removed |Added Severity|major |normal --- Comment #7 from Glenn Adams gl...@skynav.com 2012-04-07 01:37:07 UTC --- resetting severity from major to normal pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #6 from Deepthi Bakkavemana deeb...@gmail.com 2011-06-07 12:06:22 UTC --- Hi, I haver tried with . as delimiter and I dont find any change or any improvement while exporting to pdf.Please comment if you have any suggestions Thanks, Deepthi -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #4 from Abhijeet abhijeet.i...@gmail.com 2011-05-19 13:50:47 UTC --- Hi Andreas, This data is coming as a part of the feed so I have no direct control over it. Most of the times we do get only small paragraphs in it. 1. Your suggestion of adding (linefeed-treatment=preserve) somehow didn't have any visible affect. I am putting the XSL below. However, I did see that this reduced the memory usage which doesn't grow exponentially anymore. I added tag to the block and other places too :-( 2. Interestingly it looks that a default line break is coming in all the feeds that have large content. eg. Interactivelt;brgt;Group connections222 :lt;brgt; Can I use the custom BR tag to improve performance and reduce memory foot print ? A writeup is mentioned at http://www.stylusstudio.com/xsllist/200312/post00590.html 3. Is there any other way to optimize performance findBreakingPoints by compromising formatting ? Like you mentioned a paragraph of larger than 50 thousand characters in difficult to read anyways. All I want is that the paragraph gets printed even if ill formatted. Thanks in advance. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #5 from Andreas L. Delmelle adelme...@apache.org 2011-05-19 18:07:16 UTC --- (In reply to comment #4) 1. Your suggestion of adding (linefeed-treatment=preserve) somehow didn't have any visible affect. I am putting the XSL below. However, I did see that this reduced the memory usage which doesn't grow exponentially anymore. I added tag to the block and other places too :-( By 'no visible effect', do you mean in the output? 2. Interestingly it looks that a default line break is coming in all the feeds that have large content. eg. Interactivelt;brgt;Group connections222 :lt;brgt; Can I use the custom BR tag to improve performance and reduce memory foot print ? Definitely. That gives the line-layout algorithm hints about where a break MUST occur, and that allows at least some optimization, however... (see below) A writeup is mentioned at http://www.stylusstudio.com/xsllist/200312/post00590.html ... In cases where you are sure that the br/ just appears in between plain text, it is more optimal to transform it into a literal linefeed character (U+000A), and set linefeed-treatment on the parent block. That will reduce memory usage even further. Empty blocks generate enough overhead to justify avoiding too many of those. 3. Is there any other way to optimize performance findBreakingPoints by compromising formatting ? Like you mentioned a paragraph of larger than 50 thousand characters in difficult to read anyways. All I want is that the paragraph gets printed even if ill formatted. See above: I think that, apart from injecting forced breaks in the input, I do not immediately see a way to optimize further. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #1 from Mehdi Houshmand med1...@gmail.com 2011-05-18 13:02:45 UTC --- Have you tried using FOP 1.0? 0.20 is no longer supported. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 Abhijeet abhijeet.i...@gmail.com changed: What|Removed |Added Version|0.20.1 |1.0 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #2 from Abhijeet abhijeet.i...@gmail.com 2011-05-18 13:06:27 UTC --- Corrected the version. It is 1.0. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51218] FOP is unable to create PDF if there is an unusually large paragraph.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51218 --- Comment #3 from Andreas L. Delmelle adelme...@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 (plural). 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 process. 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.
