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: [email protected] > For additional commands, e-mail: [email protected] > 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: [email protected] For additional commands, e-mail: [email protected]
