> -----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)



Reply via email to