Andreas,
I fear I didn't understand the question correctly, how do I read the
files back in?
I call the xslt processor from within a java program and write the resulting fo
files to a specific directory. Then I loop through the directory and send every
file to the fo processor. So there is no 'piping', just writing a file and
reading a file. Piping is what I would like to do, but I have no idea how?
Hence my question.
I looked at iText in a different context and it worked well then but I would
prefer to stay just within xsl:fo if possible.
Erwin
-----Ursprüngliche Nachricht-----
Von: Andreas L. Delmelle [mailto:a_l(_dot_)delmelle(_at_)pandora(_dot_)be]
-----Original Message-----
From: Kloeck, Erwin
I have to create several pdf-files out of one xml document.
Currently I write several fo-files using redirect:write to disk
during xsl processing and then read them in again for fo
processing. This strikes me as sub optimal. Does anybody have
any ideas or pointers for a more straight forward process, i.e.
one not requiring the intermediate writing to disk?
Hi,
Just happens that I posed a question regarding support for this type of
scenario of fop-dev two days ago, so I'm more than interested in the way you
read the redirected files back in...
The way I understand it, the redirected files can be considered as
'side-effects' of the main transformation, but I was curious to find out in
what way a piped FO processor could keep track of these, and what would be
the best way of triggering a rendering-run for them (--redirection
extensions being an XSL processor-specific matter).
For the moment, depending on the actual requirements (i.e. whether you use
page-numbering in your XSL-FO) your best bet may be to try not to redirect,
keep them in a single fo:root and use a tool like iText
(http://www.lowagie.com/iText/) to cut up the pdf after processing.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list