[ 
https://issues.apache.org/jira/browse/FOP-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465878#comment-15465878
 ] 

Glenn Adams commented on FOP-1936:
----------------------------------

The fact of the matter is that it is extremely unlikely anyone would ever make 
an effort to optimize memory footprint for KnuthNodes for a use case that makes 
no sense. So, as I said, keep your paragraphs to a reasonable size.

> FOP is unable to create PDF if there is an unusually large paragraph.
> ---------------------------------------------------------------------
>
>                 Key: FOP-1936
>                 URL: https://issues.apache.org/jira/browse/FOP-1936
>             Project: FOP
>          Issue Type: Bug
>          Components: unqualified
>    Affects Versions: 1.0
>         Environment: Operating System: All
> Platform: PC
>            Reporter: Abhijeet
>            Assignee: fop-dev
>         Attachments: warrencounty.fo
>
>
> Hi,
> We have two problems :
> 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 ?
> 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 :-(.
> 2. FOP gives a SAX Exception on having a long paragraph in Systems which dont 
> have 1.5 GB RAM for a simple paragraph which has 90K Characters. Below is the 
> exception 
> javax.xml.transform.TransformerConfigurationException: 
> javax.xml.transform.TransformerException: org.xml.sax.SAXParseException: The 
> element type "xsl:template" must be terminated by the matching end-tag 
> "</xsl:template>".
>                 at 
> org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:995)
>                 at 
> com.ca.calm.reporter.pdf.PDFGenerator.buildPdf(PDFGenerator.java:1271) 
> Caused by: javax.xml.transform.TransformerException: 
> org.xml.sax.SAXParseException: The element type "xsl:template" must be 
> terminated by the matching end-tag "</xsl:template>".
>                 at 
> org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:991)
>                 ... 6 more
> Caused by: org.xml.sax.SAXParseException: The element type "xsl:template" 
> must be terminated by the matching end-tag "</xsl:template>".
>                 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown 
> Source)
>                 at 
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
>                 at
> Is there a way, I can prevent this extensive memory usage and slow 
> performance by using a default break ? I am ready to build the JAR myself. Is 
> this a bug which has already been fixed ?
> thanks,
> Jeet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to