> -----Original Message----- > From: Clay Leeds [mailto:[EMAIL PROTECTED] > > > In my application we create multiple page-sequences using multiple > "xsl:include" templates, which _look_ different, but are still one PDF > file. If certain flags are set in my source XML, my app creates: 1) a > bill; 2) a disclaimer; 3) a letter; 4) an extra document. All except > the Bill are optional. I suppose that, using iText or some other > post-processor, these could be extracted into separate files.
Yup, I advised him to take a look at iText. Apparently, he already had, but wanted to keep it strictly an XSL-FO solution... > Even better, of course would be "no workaround" needed, whereby > FOP would just create separate files. Better still, would be for FOP to > create separate files, *and* be able to link portions on-the-fly. > His own (preliminary) solution was to re-open the redirected files in his application (using embedded FOP) after the main rendering run. Indeed suboptimal as he himself stated (open/close/open/close...) Far better would be if we could somehow get a handle to the streams the redirection extension writes to. Place a buffer in between, and we're set. Much faster, no need for a workaround of any kind. But here, I think, is the point Glen was concerned about: the XSL processor might suddenly decide to drop the reference to that stream (upon finishing one file) and close it... how would we make sure the stream stays opened until FOP is finished with it? And then there's the question on whether you would want FOP to wait to start a new Driver run until the main one finishes, or whether you would want to start a new run in a different Thread (--good exercise this would be, that's for sure) Cheers, Andreas
