xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis van Zoerlandt <dvzoerla...@vanboxtel.nl>
Subject Re: AW: AW: AW: AW: OutOfMemoryException while transforming large XML to PDF
Date Mon, 04 Apr 2011 09:33:00 GMT

Hi Andreas,

Andreas L. Delmelle wrote:
> 
> On 01 Apr 2011, at 13:13, Dennis van Zoerlandt wrote:
> 
> Hi Dennis
> 
>> I will look further into modifying the XSL file in a such way multiple
> 
>> page-sequences are used. I think it's the best solution this far. Am I
>> correct to say multiple page-sequences won't affect the definitive page
>> lay-out of the PDF file?
> 
> As Georg already pointed out, starting a new page-sequence is like
> inserting a forced page-break. A page-sequence should be seen as a
> chapter, i.e. isolated/separated from all other content.
> 
> Depending on the exact use case, this might be impossible. If you
> absolutely need to have one continuous flow of 455 pages, increasing the
> heap would really be the _only_ way out. 
> If you can live with some pages not being filled entirely, you can perhaps
> create new page-sequences at points where it makes sense to see a
> page-break in the output.
> 

Alright, I need to discuss this with the stylesheet author. I think there
should be a possibility to create a page-sequence after each activity block.

Andreas L. Delmelle wrote:
>  
>> How can I split up the content in multiple
>> page-sequences? I think there's also a modification necessary in the XML
>> input file?
> 
> Not necessarily. If you really want to, you can already group your source
> nodes in there, obviously, but that grouping can probably also be coded
> into the XSLT.
> 
> To find out more about grouping in XSLT, Google around some. There is lots
> and lots of info available about this on the web.
> 

That's the answer I needed, because the stylesheet could be possible easier
to adapt than the XML file. I'll Google for this.

Andreas L. Delmelle wrote:
> 
>> Another question: is there a reliable way to 'predict' or calculate the
>> page
>> count the PDF file will have, before any transformation is started?
> 
> Not really, unless the document structure is very simple and predictable.
> Otherwise, FOP will compute those page-breaks, so it's the chicken and the
> egg: you would need to process your document to know if you want to
> process it...
> In case of your test file, I can see that 11 of the detail tables (header:
> Status - Start - End Act no....) fit together in one page, plus the static
> content. If the content is really that predictable, you could stop if your
> document would generate 1100 of those tables.
> 
> At any rate, if there were a straightforward way to handle this for any
> arbitrary document, it would likely have already found its way into FOP.
> 

Seems obvious. In this case I could compute an estimated page count for this
stylesheet, unfortunately I have many stylesheets which are more complex
than this one, which should mean I have to write a page count algorithm for
each stylesheet. It's not a preferable option in my case, you'd create a
link between the stylesheets and the FOP process, something I'd rather keep
unlinked.

Andreas L. Delmelle wrote:
> 
> Regards
> 
> Andreas
> ---
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 

Best regards,
Dennis van Zoerlandt
-- 
View this message in context: http://old.nabble.com/OutOfMemoryException-while-transforming-large-XML-to-PDF-tp31236044p31312719.html
Sent from the FOP - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message